Skip to main content

Workflow Builder

The Workflow Builder is a visual, drag-and-drop interface for designing governance processes. It uses a node-based canvas where you connect triggers, decisions, approvals, and actions into a complete workflow graph.

The Canvas​

Overview​

The builder presents a full-screen canvas powered by a graph visualization engine. Workflows are represented as directed graphs — nodes represent steps, and edges represent the flow between them. Every workflow begins with exactly one Trigger Node and flows through subsequent nodes until it reaches a terminal state.

Zoom in and out using the scroll wheel or pinch gestures. Pan by clicking and dragging on the canvas background. The minimap in the corner provides an overview of complex workflows, and the controls toolbar offers zoom-to-fit and reset options.

Node Palette​

Adding Nodes​

The side palette lists all available node types. Drag a node from the palette onto the canvas to add it to your workflow. Once placed, click a node to select it and configure its properties in the right-hand panel.

Connecting Nodes​

To create a connection, drag from the output handle of one node to the input handle of another. Decision nodes have multiple output handles — one for each branch (e.g., "True" and "False"). Each node type has specific connection rules to ensure valid workflow graphs.

Node Types​

Trigger Nodes​

Every workflow must start with exactly one trigger. Triggers define what event initiates the workflow.

Access Request triggers activate whenever a user submits an access request to a product or role. Change Request triggers fire when a change request is submitted for a data product. Manual triggers create workflows that can be started on-demand by an administrator. Scheduled triggers accept a cron expression (e.g., 0 9 * * 1 for every Monday at 9 AM) and run the workflow automatically at the defined interval.

Decision Nodes​

Decision nodes evaluate conditions and route the flow to different branches based on the result.

Simple Condition nodes evaluate a single boolean expression against the workflow context. For example, context.priority == 'Critical' splits the flow into a True (green) path and a False (red) path. Switch/Case nodes route to one of multiple paths based on a variable's value, with a default fallback for unmatched values.

Conditions can reference any property from the request context, including fields like priority, risk level, product metadata, and requester department.

Approval Nodes​

Approval nodes pause execution and create review tasks for designated users.

In the configuration panel, you specify the Strategy — whether the approver is a named user, a governance role (like "Owner" or "Steward"), or the product owner. You also choose the Step Type, which determines whether it is a single approval, parallel (all must approve), or sequential (one after another) process. Approval nodes display the reviewer's name once assigned, or show the role label (e.g., "Security Approval") while pending assignment.

Action Nodes​

Action nodes execute automated tasks without human intervention.

Notification actions send messages via email, Slack, or webhook, using configurable templates and recipients. Update Record actions modify fields on the related entity — for example, automatically marking a request as "Approved." Create Ticket actions generate a new issue in the Issue Tracker for manual follow-up tasks, such as provisioning access in legacy systems. Script actions execute a sandboxed Python snippet for custom logic, such as computing a risk score on-the-fly.

Configuring Nodes​

Property Panel​

Select any node to open the property panel on the right side of the canvas. Each node type exposes different configuration options. Common settings include Label (a human-readable name displayed on the canvas), Description (internal notes for workflow administrators), and type-specific options such as conditions, approval targets, or notification templates.

Context Variables​

Workflows operate on a shared context object that carries data from the triggering event. You can reference context variables in decision conditions and action templates using the context.variable_name syntax. Common context variables include context.priority, context.product_id, context.requester_id, and any custom metadata passed at trigger time.

Managing Workflows​

Saving​

Click Save to persist your workflow definition. The platform versions your changes automatically, so you can track the evolution of a workflow over time.

Activating and Deactivating​

Toggle the Active status to control whether a workflow responds to triggers. Deactivating a workflow does not affect instances that are already running — they will complete normally. Only active workflows are evaluated when new events occur.

Deleting​

Deleting a workflow removes the definition entirely. Active instances of a deleted workflow will continue running to completion but no new instances will be created.

warning

Deleting a workflow is irreversible. Consider deactivating instead if you may need the workflow again in the future.

Debugging and Monitoring​

Live Execution View​

When a workflow instance is running, the canvas overlays the current execution state. The active node is highlighted, completed nodes show a success or failure indicator, and the execution path traces the route taken through the graph.

Execution History​

Each workflow definition tracks all of its instances. You can view the current status (running, completed, failed), the execution path taken through the graph, timestamps for each transition, and approval decisions with reviewer details.

Retrying Failed Instances​

If an instance fails at a specific node — for example, due to a temporary connectivity issue — administrators can retry execution from that node. You can optionally update context variables before retrying to fix configuration issues.

Best Practices​

Start with Templates​

Use the built-in templates as a starting point rather than building from scratch. Duplicate a template, then customize it to match your organization's requirements.

Keep it Simple​

Avoid overly complex graphs with many branches. Simpler workflows are easier to understand, debug, and maintain. If a process has many conditional paths, consider splitting it into multiple focused workflows.

Use Role-Based Approvers​

Prefer governance roles (like "Owner" or "Steward") over hardcoded user IDs. This makes workflows resilient to team changes — when someone leaves or changes roles, the workflow automatically routes to the new assignee.

Test with Manual Triggers​

Before linking a workflow to an automated trigger, test it using the Manual trigger type. This allows you to validate the logic in a controlled setting before it processes real requests.