Working on a workflow as a team

A workflow belongs to its workspace, not to the person who made it: everyone in the workspace can open it, and every Admin and Editor can change, test and publish it. This article explains how that works when several people look after the same workflow, and how to avoid overwriting each other's work.

Who can do this

It depends on your workspace role. Your company role (Owner, Admin, Member) makes no difference.

Viewers see the same canvas as everyone else, with no +, no Publish and no Test run. See What each role can do.

Steps

There is one draft per workflow, and everyone edits that same draft. Bizomate does not lock it, and does not show who else has it open. So agree who is changing a workflow before you start, then:

1. Before you change anything, reload the designer if it has been open for a while. The designer shows the draft as it was when you opened it; it does not pick up changes others have saved since.
2. Make your changes. Each one is saved to the draft as you make it, and the pill beside the name says so — Draft · autosaved just now, then Draft · autosaved 2 min ago. This only describes your own saves.
3. Tell the others when you have finished, so they reload before they start.
4. Select Publish, and say what changed in What changed? — for example Sends the summary to Asha as well — so the others can see it in Versions. See Publish a workflow.

What happens next

When two people edit the draft at the same time, nothing is lost. If Asha Raghunathan saved the draft after you opened it, your designer's next save stops: autosave pauses, and a banner says who saved and when. You see what changed, then save yours as a copy, load hers, or keep yours. See When someone else changed the draft.

• Publishing is checked the same way: if someone saved after you opened the draft, Publish publishes nothing until you choose.
• Undo (Ctrl Z) goes back through your own changes since you opened the designer. Each undo is a save, checked like any other.
• Pinned outputs and sticky notes are part of the draft, and the same check covers them.
• Test results: when you open the designer it shows the latest test runs of the workflow, whoever ran them. Only one test of a workflow runs at a time, and the workspace's daily test runs are shared by everyone in it.
• Test in: is remembered for each person, so a colleague can test in Production while you test in Development. See Choose the environment a test runs in.
• After a publish, the workspace's other Admins get a notice in the notification centre: Daily sales summary published as v3 — Consulace workspace, by Rohan Mehta., with Open workflow. Editors and Viewers are not told.
• Versions keeps who published each version and when — 12 Sep, 16:40 · Asha Raghunathan — with its note. To see what someone changed, select Compare beside a version. To undo a published change, restore an earlier version into the draft and publish it. See Compare two versions of a workflow and Restore an earlier version.

Who hears when something goes wrong

Every Admin and Editor in the workspace is told — not only the person who built or published the workflow. Viewers are not.

• A run fails: a notice in the notification centre, Daily sales summary failed, with View run, for every Admin and Editor. The first failure also comes by email to those who have A run fails switched on. When it runs successfully again, the notice gives way to Daily sales summary is running again.
• A connection stops working: Consulace Outlook needs reconnecting, with Reconnect, to every Admin and Editor, and by email to those who have A connection stops working switched on.
• Someone revokes a connection: the other Admins and Editors are told — Rohan Mehta revoked Consulace Outlook — Workflows in Consulace that use it fail until it is reconnected.
• A key or password is about to expire: a reminder goes to the workspace's Admins only.
• An app trigger stops checking: the workflow is switched off and every Admin and Editor gets Daily sales summary is paused, with Open the workflow.

To stop the emails, switch them off in Settings › Notifications. The notices in the notification centre still come. See Choose which emails you get.

Good to know

• Connections are shared by everyone in the workspace, and any workflow in it can use any of them. A connection's panel says who added it — connected 12 March by Rohan Mehta — and which workflows use it. See Using the Connections page.
• A step that acts as a person — a Slack step with Post as me — acts as whoever switched it on, and says so on the step: Acts as Asha Raghunathan, who has not connected their own Slack account yet — the step fails until they do. It keeps acting as that person whoever publishes it.
• Projects group workflows in a workspace; they do not limit who can see or change them. See Grouping workflows into projects.
• There is no "last edited by" on the Workflows list. It shows each workflow's project, state and last run. To see who saved the draft and when, open Versions › Unpublished saves, which keeps the last 10 saves. See See and restore unpublished saves.
• Run history is shared: everyone in the workspace sees every run of every workflow on Runs.
• Role changes count at once. Someone changed from Editor to Viewer still sees the designer's editing buttons until they switch workspace or sign in again, or for about 30 minutes, but nothing they try is saved: saving, publishing, switching on, running, renaming, moving, copying and deleting are each refused from the moment the role changes — and so are creating, renaming and deleting projects, and adding, changing, revoking and deleting connections.

If something goes wrong

Related

• Publish a workflow
• Compare two versions of a workflow
• Restore an earlier version
• What each role can do
• Choose which emails you get