--- title: "Workflow Studio Guide" slug: help-workflow-studio section: In-App Help status: stable description: "In-app help · Building and managing applicant workflows" last-updated: 2026-10-07 --- # Workflow Studio Guide In-app help · Building and managing applicant workflows ## What Is Workflow Studio? Workflow Studio is the visual editor for designing applicant workflows. It lets you define the steps an applicant goes through — from initial application to program completion — using a drag-and-drop canvas. Each workflow template can be customised per program and season. > **Architecture Reference** > > For the full technical specification of Workflow Studio, including node types, conditional logic, and the rules coverage panel, see the Workflow Studio architecture page. For the metadata every field on a step must carry so Globus can route the captured value to the right table and partner surface, see the Field Classification Contract . ## Getting Started Access Workflow Studio from Admin > Program Configuration > Workflow Studio. ## Canvas Basics The canvas is where you design your workflow visually: ## Adding & Configuring Steps Each step in a workflow has configuration options: ## Working with Phases Phases structure your workflow into logical stages. Each phase has a completion gate that determines when an applicant can advance to the next phase. Gates can be automatic (all required steps completed) or manual (staff must click “Advance”). Phase Operations Add Phase / Rename Phase / Reorder Phases / Delete Phase ## Limits & Guardrails (7 / 6 caps) Workflow Studio enforces two structural caps so the applicant portal stepper stays readable on the first screen an applicant ever sees: Max 7 applicant-facing steps per phase The cap counts applicant-facing steps only — behind-the-scenes steps (e.g. interviews) never render on the stepper and do not count. If a phase needs an 8th applicant-facing step, split it into a new phase. The portal stepper renders steps as a horizontal row of numbered circles — more than 7 wraps and breaks layout. Max 6 phases per workflow Phases render as top tabs above the stepper. Beyond 6 the tab row wraps and the workflow becomes hard to navigate. Authoring-time soft warning When you drag in the 8th step of a phase, or the 7th phase of a workflow, Workflow Studio shows an inline warning recommending you restructure. The draft still saves — the warning is informational, not blocking. Publish-time hard validation Clicking Publish on a draft that exceeds either cap is rejected with a validation error listing every offending phase. No new published version is created until the workflow is restructured. Legacy workflows are blocked from re-publishing Any workflow published before the caps existed that still exceeds them is flagged as non-compliant. It continues to run on its current published version, but it cannot be re-published until it has been manually restructured. Karin Brettenny is notified by email with the full list of affected workflows so her team can coordinate the rework. There is no automatic migration. > **Portal renders defensively** > > If a published workflow ever reaches the applicant portal with more than 7 steps in a phase or more than 6 phases (legacy data, override path, or bug), the portal falls back to horizontal scroll on both the step row and the phase-tab row — it never wraps, truncates, or hides steps. The portal is not the enforcement point; see Applicant Lifecycle — Portal Phase Mapping for the rendering contract, and Workflow Studio — Publish-Time Cap Validation for the enforcement rules. The two drafted Asana tickets covering enforcement and the applicant-portal scroll fallback live in the Implementation Tickets — Step & Phase Caps appendix on the Workflow Studio page. ## Publishing & Versioning Workflows use a draft/published model: > **In-Progress Applications** > > Publishing a new version does not affect applications already in progress. Each application is pinned to the workflow version it started with. Only new applications pick up the latest published version. ## Approval Prompt on Content Changes When you publish a new version for a program that has active applications, Workflow Studio blocks the publish with a 409 (`PUBLISH_BLOCKED_BY_ACTIVE_APPLICATIONS`) that reports how many applications are active. A system admin must acknowledge that those in-flight applicants will need reconciliation onto the new version (the `acknowledgeActiveApplications` confirmation) before the publish proceeds. The prompt is not limited to material step changes and does not list affected steps. Optional publish notes can be supplied with the publish. A program with no active applications publishes without the prompt. ## Why a Step Edit Can Be Blocked Editing a step in the Step Library or directly inside a workflow can be blocked if applicants are actively working on that step right now. Studio will show the affected programs by name and the number of active applicants, so you know exactly what’s in the way. Studio never silently rewrites a step under an applicant’s feet. To make the change, either wait for those applicants to clear the step or draft a new step and publish a new workflow version that picks it up — the Approval Prompt above will let you confirm the cutover. ## Testing Your Workflow Before publishing, use Test Application Flow to simulate the applicant experience. This creates a sandboxed test application that walks through every step without affecting real data. You can test conditional branches, verify step visibility, and confirm phase gates work as expected. ## Tips & Best Practices Start by cloning an existing workflow that\u2019s close to what you need, then modify it / Keep phases to 4\u20136 for clarity \u2014 6 is the hard cap and Publish will reject any 7th phase. See \u201cLimits & Guardrails\u201d above / Keep steps per phase to 7 or fewer \u2014 this is the hard cap. If a phase needs an 8th step, split it into a new phase before you click Publish / Use Hub nodes to group related sub-steps (e.g., \u201cDocuments\u201d hub containing 5 upload steps) / Set SLA targets on review steps to drive accountability and enable escalation / Use Placeholder nodes for steps you plan to build later \u2014 they\u2019re skipped at runtime / Always test before publishing. Use the Test Application Flow to walk through every branch / Review the Rules Coverage Panel to ensure every workflow step is covered by validation rules ## Common Questions