--- title: Graphical Workflow Designer Overview slug: graphical-workflow-designer-overview docTags: createdAt: 2026-02-19T02:03:39.089Z --- The Graphical Workflow Designer in Activate is used to design and manage workflows that control how tasks are processed. Workflows define the sequence of steps, decision points, approvals, automation, notifications, and completion logic required to fulfil a request. Workflows are constructed visually using configurable activities connected by transitions. Each activity performs a specific function, allowing complex orchestration logic to be implemented in a structured and maintainable way. The designer supports both automated and human-driven processes, making it suitable for access management, provisioning, approvals, and service fulfilment scenarios. # Core Workflow Concepts ## Activities Activities represent individual steps within a workflow. Each activity performs a defined action and passes control to the next activity based on transitions and outcomes. Common activity types include: - Approval - Script execution - Fork (parallel processing) - Join / wait for completion - Notification - Decide (conditional branching) - Delay - Submit Ticket - End Workflow Each activity can be configured using expressions, role resolution logic, and script code where required. ## Transitions Transitions define how the workflow moves between activities. Transitions may be: - Unconditional - Based on approval outcomes (Approved / Declined) - Based on decision logic - Based on script results Clear transition design ensures predictable workflow behaviour. ## Fork and Join A fork allows the workflow to branch into multiple parallel paths. A corresponding join or wait step ensures processing does not continue until required branches have completed. Fork and join are commonly used for: - Multi-owner approvals - Parallel validation steps - Independent processing tasks that must complete before continuation # Example: Request Access to Distribution List The following example demonstrates a typical access management workflow. ![](https://api.archbee.com/api/optimize/Lfto9rn2ELed8aLNOgwlJ/kWfrncbi1H927k0xJ-YLj_image.png "Activate's workflow designer") ::Image[]{src="https://api.archbee.com/api/optimize/Lfto9rn2ELed8aLNOgwlJ/RwyFZFs6vxKxb5_EAaxSw_image.png" size="36" width="342" height="399" position="center" caption="Workflow designer available activities" showCaption="true"} ## Step 1: Owner Resolution and Fork When a user submits a request to join a Distribution List (DL), the workflow begins by determining the owners of that DL. If multiple owners are configured, the workflow forks into separate jobs, one per owner, so that each owner receives an individual approval action on a job. This ensures: - Independent approval tracking, owners only approve access to DLs they own. - Parallel processing - Clear audit history ## Step 2: Owner Discovery (If No Owners Are Set) If no owners are explicitly configured on the Distribution List, the workflow performs owner discovery using a script activity. This script: - Inspects the members of the Distribution List - Emails members of the DL for an owner to volunteer. - Populates the approval target list dynamically This ensures that approval can still proceed even when ownership is not explicitly defined. ## Step 3: Wait for Owner Discovery Completion Because owner discovery may involve background processing, the workflow includes a wait or synchronisation step to ensure owner resolution has completed before proceeding. The approval stage is not triggered until owner determination is complete. ## Step 4: Approval Each identified owner receives an approval to action. Depending on configuration, the workflow may require: - All owners to approve, or - A defined approval condition (for example, one approval sufficient) If an owner declines, the workflow transitions to the decline path. ## Step 5: Decline Path If the request is declined: - The submitter is notified - The workflow ends with a declined status - No automation is executed ## Step 6: Approved Path – Automation If approval is granted, a script activity performs the required automation. In this case, the script: - Adds the target user to the requested Distribution List - Performs validation checks - Handles any errors or exceptions Automation may interact with directory services or other systems via Activate Orchestrator. ## Step 7: Completion Notification After successful automation: - The submitter is notified that access has been granted - The workflow transitions to a completed state # Additional Workflow Activities In addition to approvals, scripts, fork, and join, the Graphical Workflow Designer supports the following configurable nodes. ## Decide (Conditional Branching) The Decide activity evaluates an expression and routes the workflow based on the result. This functions as an if/else decision tree. It is typically used to: - Apply different approval rules based on department or risk - Skip steps when conditions are already satisfied - Escalate requests under defined criteria Decide nodes support multiple conditional branches and a default path. ## Delay The Delay activity pauses the workflow for a specified duration before continuing. Delays can be configured using: - Fixed time intervals - Calculated expressions - Date-based conditions Common uses include: - Escalation windows - Synchronisation with external systems - Reminder intervals - Time-based expiry logic ## Submit Ticket The Submit Ticket activity creates a ticket in an integrated service management system. This is used when: - Manual intervention is required - Automation cannot proceed - Escalation to operational teams is necessary The ticket can include job metadata, approval details, and custom arguments. The workflow can either continue immediately or wait for further input, depending on configuration. ## End Workflow The End Workflow activity explicitly terminates the workflow. While workflows naturally end when no transitions remain, using an explicit End Workflow node: - Improves readability - Clearly defines termination states - Separates successful, declined, cancelled, and error outcomes Explicit end nodes are recommended for all completion paths. # Design Considerations and Best Practice When designing workflows in Activate: - Keep approval and business logic visible in the workflow where possible. - Use Decide nodes instead of embedding all conditional logic in scripts. - Ensure forked paths always have appropriate join or completion handling. - Include clear decline and error paths. - Use Delay carefully to avoid unnecessarily long-running jobs. - Ensure automation scripts include validation and error handling. - Use explicit End Workflow nodes for clarity. The Graphical Workflow Designer enables structured, auditable, and automated service fulfilment processes. By combining approvals, conditional logic, automation, and notifications, it supports complex business requirements while maintaining visual clarity and maintainability.