Workflows for Org Unit and Location Admins

Org Unit Admins and Location Admins can create and manage their own Workflows, scoped to the org unit they administer. This article explains what an org-unit-scoped Workflow is, how it differs from a global Workflow, and which triggers and actions are available.

Who this applies to

• Org Unit Admins and Location Admins can create, edit, activate and run Workflows for the org units or locations they administer.
• Global Admins can still create global Workflows, and can also create Workflows scoped to any org unit.
• Org-unit-scoped Workflows are available on the CORE and PREMIUM plans. Your tenant must have Organizational Units enabled.

What is different about an org-unit-scoped Workflow?

Every Workflow has a scope: Global, or one org unit. You choose it when you create the Workflow, and it cannot be changed later.

A Workflow scoped to an org unit works like a global one, with these differences:

• It only reacts to its own org unit. A "User created" trigger fires only for users in that org unit. Events elsewhere are ignored. See Triggers.
• Subunits are included. A Workflow for "Germany" also covers "Berlin" and "Munich" if they are subunits of Germany. A Workflow for "Berlin" does not cover "Munich".
• It uses its own bot. The Workflow runs with a bot that only has permissions in that org unit. See The scoped automation bot.
• The scope is fixed. It stays the same no matter who edits the Workflow, including Global Admins. For another org unit, create a new Workflow.
• Some triggers and actions differ. A few are hidden or work differently because the bot has no tenant-wide permissions. See the sections below.

The Workflow list follows the org unit selected in the sidebar

The Workflows page now follows the org unit selector in the Dashboard sidebar:

• At the Global level, Global Admins see all Workflows. Org Unit Admins see the Workflows of every org unit they administer.
• When you select an org unit in the sidebar, the list shows only the Workflows scoped to that org unit and its subunits.

Note: The default name of a new Workflow includes the org unit, e.g. "Workflow 3 Berlin". The number counts the Workflows already in that org unit (subunits excluded).

How do I create an org-unit-scoped Workflow?

1. Go to the Dashboard and click on "Toolbox", then "Workflows".
2. Optionally, select the org unit in the sidebar first. The Workflow list will then show only the Workflows of that org unit.
3. Click on "Create new Workflow" (first Workflow) or "Add New" (if Workflows already exist).
4. In the "Where do you want to use this workflow?" dialog, pick the org unit or location the Workflow should apply to and click "Select".
   • The dialog shows the org unit selected in the sidebar and its subunits. Use the search bar to find a unit quickly.
   • Selecting the top-level (Global) unit creates a global Workflow. Only Global Admins can do this.
   • Org Unit Admins and Location Admins only see the units they administer.
   • If the selected org unit has no subunits, the dialog is skipped and the Workflow is scoped to that unit directly.
5. In the "Workflow settings" panel, enter the Workflow name and optionally a description. The default name already contains the org unit, e.g. "Workflow 3 Berlin".
6. The Delivery Bot is pre-selected: it is the automation bot of the chosen org unit (see the next section). You can pick a different bot, but only bots scoped to that same org unit are listed.
7. Add a trigger, then add your actions, exactly as described in Creating and editing a Workflow. Triggers and actions that are not available for org-unit-scoped Workflows are not shown in the list.
8. Save the Workflow to validate it, then activate it with the "Active" toggle.

Note: The scope cannot be changed once the Workflow is created. If you need the Workflow in another org unit, create a new Workflow with that scope.

How do I edit an org-unit-scoped Workflow?

1. Go to the Dashboard, click on "Toolbox" and select "Workflows".
2. If the Workflow is not in the list, check the org unit selected in the sidebar. Select the Workflow's org unit, one of its parent org units, or Global.
3. Click on the Workflow you want to edit and follow the same steps as when creating a new Workflow.

As an Org Unit Admin or Location Admin, you can only open, edit, activate and deactivate Workflows that belong to org units you administer.

The scoped automation bot

Global Workflows run as the "Workflow Automation Bot", a bot with Global Admin permissions. An org-unit-scoped Workflow cannot use that bot. Instead, each org unit gets its own automation bot.

• Name: "{Org Unit Name} Automation Bot", e.g. "Berlin Automation Bot". The bot is created automatically the first time someone opens the Workflow editor for that org unit.
• Permissions: the bot is an Org Unit Admin of that org unit only. It can only read and change users, groups, streams, forms and other content that belong to the org unit and its subunits.
• Default delivery bot: the bot is pre-selected as the Delivery Bot of every Workflow scoped to that org unit. All messages, posts and tasks sent by the Workflow appear under this bot's name.
• Only bots of the same org unit can be selected. The Delivery Bot picker never shows the global Workflow Automation Bot or bots of parent org units. If a bot of another scope is assigned, saving the Workflow fails with an error.

The bot's memberships are managed automatically

Unlike the global Workflow Automation Bot, the scoped bot is not added to groups or locations by hand. Its group memberships, location memberships and admin permissions are set automatically when the bot is created and cannot be changed by admins, user imports or automations. The bot can work with every group that belongs to its org unit, because it is an admin of that org unit.

Because the bot cannot join groups or receive individual permissions, it can only reach streams, forms, schedules and events that are available to its org unit. A trigger on such content only fires, and an action on it only succeeds, when the bot has that access. If a Workflow needs content that is restricted to specific groups, ask a Global Admin to create a global Workflow for it.

Where the bot is placed

Every bot belongs to one location. The org unit's bot is placed in the org unit itself if it is a location. Otherwise it goes into the oldest location directly under the org unit.

Keep these points in mind:

• Access shared with a single location only counts if it is the bot's location. For example, the "Australia Automation Bot" sits in Sydney. It can read a form shared with Sydney, but not one shared only with Melbourne. Share such content with the whole org unit instead.
• The org unit needs at least one location. Without one, the bot cannot be created and neither can the Workflow.
• If the bot's location is deleted, the bot moves to the next location of the org unit. Workflows keep running.
• If no location is left, or the org unit is deleted, the bot is deleted and the org unit's Workflows stop working. After adding a location again, open the Workflow editor to recreate the bot and select it as the Delivery Bot.

Note: Only Global Admins can see bot accounts under Dashboard > Extensions > Bot Accounts. Org Unit Admins use the scoped bot through the Workflow editor only.

Actions that work differently or are not available

Most actions work exactly as in a global Workflow, as long as the scoped bot has access to the content involved. The following actions differ in an org-unit-scoped Workflow:

Note: The Location picker only lists locations and org units you administer, and user pickers only suggest users you administer. Pick items inside the Workflow's org unit. If you pick one outside it (for example as a Global Admin editing the Workflow), the action fails when the Workflow runs, because the scoped bot has no permission there.

Note: Actions that target users, groups, streams, forms, schedules or events only succeed for items inside the Workflow's org unit (and its subunits). For example, "Suspend user profile" fails for a user from another org unit.

Triggers

Triggers that are not available

Triggers that come from outside the platform are not available in an org-unit-scoped Workflow. This covers incoming webhooks and triggers fed by integrated systems such as payroll, scheduling, learning or HR tools. Their events are not tied to a single org unit, so they are not shown in the trigger list. If you need one of them, ask a Global Admin to create a global Workflow.

Triggers that only fire for the org unit

All other triggers are available, but they only start the Workflow when the event belongs to the Workflow's org unit or one of its subunits. What "belongs" means depends on what the trigger is about:

• Triggers about a user (for example a user being created, logging in for the first time, being suspended or activated, posting, commenting, reacting, or reaching a profile date) fire only when that user belongs to the org unit.
• Triggers about a group (a group being created, a user being added to or removed from a group) fire only when the group belongs to the org unit. For membership triggers, the user must belong to it too.
• Triggers about content (a stream post or comment, a form submission, an open shift on a schedule, an event invitation) fire only when the org unit's automation bot can access that stream, form, schedule or event.
• Triggers about another Workflow (a Workflow failing) fire only when that Workflow belongs to the same org unit.
• Time-based triggers (daily, weekly, monthly, cron) and triggers with no user or content involved fire as usual, with no org unit filter.

Note: Events that do not pass the check are silently skipped. They do not appear in the execution history as failed runs.

Workflow execution history

The execution history follows the same scope as the Workflow list:

• At the Global level, Global Admins see all executions. Org Unit Admins see the executions of Workflows in the org units they administer.
• With an org unit selected in the sidebar, the history shows only executions of Workflows scoped to that org unit and its subunits.
• Org Unit Admins can open the details of an execution and stop it, but only for Workflows in org units they administer.

Note: An execution keeps the scope its Workflow had when it started.

Limitations

Org-unit-scoped Workflows differ from global Workflows in the following ways:

• No templates. Org-unit-scoped Workflows are built from scratch. Templates are only offered to Global Admins at the Global level.
• No analytics. Workflow analytics are a Global Admin feature at the Global level.
• Fixed scope. A Workflow keeps the scope it was created with. To use an automation in another org unit, create a new Workflow there.
• One org unit per Workflow. A Workflow covers one org unit and its subunits. For several org units, create one Workflow per org unit.

FAQs

Q: I am an Org Unit Admin but I do not see the Workflows page. Why? A: Your tenant must be on the CORE or PREMIUM plan with Organizational Units enabled, and you must be an admin of at least one org unit or location. Contact your Global Admin or our Support team.

Q: I created a Workflow in "Germany". Will it run for a new user in "Berlin"? A: Yes, if Berlin is a subunit of Germany. Org-unit-scoped Workflows cover the org unit and all its subunits.

Q: Can a Global Admin see and edit my org-unit-scoped Workflow? A: Yes. Global Admins see all Workflows. Editing it does not change its scope.

Q: Why is my Workflow not triggered for a user I know exists? A: Check that the user belongs to the Workflow's org unit or a subunit. Events from other org units are ignored by design.

Q: The Workflow failed with a permission error. What should I check? A: Check that every location, group, stream or form used in the actions belongs to the Workflow's org unit, and that the scoped bot has access to restricted content.

Q: I do not see the Delivery Bot setting in my Workflow. Why? A: The Delivery Bot setting depends on your plan and is not available on all Essential plans. When it is not shown, the Workflow runs with the default automation bot of its org unit. Contact our Support team if you think it should be available to you.