Documentation

Admins and people who configure Workflows

Build, verify, and publish a Workflow

Move a process from a draft to a published Workflow, with clear conditions, a timeout path, and a check of what actually happened.

Reviewed September 21, 2026

Before you start

  • Your account must have Workflows available, and your access group must allow Automation access. Ask your admin if the area is missing.
  • Know which record or schedule should start the process and which fields the actions will read or update.
  • Use sample records and controlled recipients when checking a process that changes data or sends messages.

Steps

  1. Name the outcome

    Open the Workflow editor and give the process a clear name, such as Shift location follow up. Decide what should count as success and what should happen when the expected update never arrives.

  2. Choose the trigger

    Select the event and relevant collection, or a Schedule trigger where available. The trigger determines the record context that later conditions and actions can use. An action that needs a triggering record may be unavailable for a schedule.

  3. Configure conditions and actions

    Choose fields and values from the editor. Confirm that each branch leads to the intended action. Relative time can compare a date against the current time or another date, with an offset, where the field and operator support it. A time condition evaluates when the Workflow reaches it; it is not itself a recurring trigger.

  4. Set a deadline for an event wait

    For Wait for event, select the target record, event, and any matching conditions. Set a positive timeout of no more than 30 days. The initial timeout is 7 days. Connect the TIMEOUT branch to the response you want if the event does not arrive. An unconnected TIMEOUT branch ends that path.

  5. Verify and save

    Choose Verify and review the issues shown in the editor. Fix the reported configuration and connection problems, then verify again. Choose Save draft or Save as draft if you are not ready to make the change live.

  6. Publish deliberately

    Choose Create & publish for a new Workflow, or Publish for an existing one, and review any confirmation. Publishing makes the definition available to run from its configured triggers. Saving a draft alone does not activate it.

  7. Check a controlled run

    Trigger the process using the sample record or a controlled schedule. Inspect the resulting records and messages. Check the expected branch and the timeout or exception branch. Use the Workflows Usage view to review completed and failed runs, then investigate any unexpected outcome before expanding use.

Relative time and waiting solve different problems

A relative date condition asks whether a date matches a rule when evaluated. Wait for event pauses an existing run until a qualifying event arrives or its deadline expires. Choose the behavior your process needs rather than adding a delay and hoping the data has changed.

Actions depend on context

Approval actions require compatible request events. Ending an ongoing shift requires user context. Record locking actions appear only where that feature is enabled. Choose from supported options in your editor; an unavailable option is not a promise of account access.

Example

For a shift at Riverside Care, wait for a matching Location update for up to one day. Continue to the configured assignment action only when the event matches. Use the timeout path to notify an internal reviewer. Test both paths with a sample shift before using real staffing records.

Check your work

  • The expected trigger starts the published version.
  • A matching event takes the intended path; an unrelated update does not.
  • The timeout produces the intended result or ends the path deliberately.
  • Only the intended records and recipients are affected.

Troubleshooting

Why did my saved changes not affect the live process?

Check whether you saved a draft. Draft changes must be published before they replace the live definition. Also check whether the Workflow is paused.

Why is an action unavailable?

Check the trigger and collection first, then the account feature and permissions. Some actions need a request or user record that the current trigger does not provide.

Why did the event wait finish without another action?

Check the timeout and the TIMEOUT connection. An unconnected timeout path can end the run. Also check the selected target, event, column, and conditions before assuming an update should have matched.