Team: team workflows and shared mailboxes

Loop & Roll is built for a team. A team workflow is visible to every member and works on the shared mailboxes (sales operations, accounting); a personal workflow only concerns you and your own mailboxes — “my own email”.

Team or personal workflow

	Team workflow	Personal workflow
Who sees it	every member of the organisation	you only (not even an administrator sees it)
Who changes it	administrators and editors	you
Who publishes, pauses, takes it offline	administrators	you
Who starts a test run	every member	you
The mailboxes it listens to and writes from	the shared mailboxes	your personal mailboxes
The connections it uses	the organisation’s connections	the organisation’s and yours

A new workflow is a team workflow by default when you are an administrator or an editor — including from a template, the assistant or the analyzer. A member creates personal workflows. The choice is made in New workflow → From scratch (“For whom: the team / just me”).

The workflow list shows each one’s scope (a Team or Personal badge) and filters by scope.

Sharing a personal workflow. The card’s “…” menu → Share with the team. The workflow becomes visible to everyone; if it is published, it now listens to the shared mailboxes, and sharing is refused while its live version writes from one of your personal mailboxes or uses one of your personal connections (change it, publish again, then share).

Making a team workflow personal is an administrator’s action (“…” menu → Make personal).

What a team workflow may use

A team workflow uses only shared mailboxes and organisation connections: it must not stop working when a colleague leaves, nor write on their behalf without them knowing. The editor flags a personal mailbox or connection on the field concerned, saving refuses it when you have just chosen it, and publishing always refuses it.

The Email received trigger has a Watched mailbox setting: empty, it listens to every mailbox of the workflow’s scope (every shared mailbox for a team workflow); filled in, it listens to that one only. To listen to two specific mailboxes, add two triggers.

Roles

Role	Can
Member	see team workflows and start test runs; handle the Review and see the activity of the shared mailboxes opened to them; create and publish their personal workflows
Editor	everything a member can, plus create and change team workflows — without publishing them
Administrator	everything: publish, pause and take team workflows offline, manage members, share mailboxes and set their access, and the whole Administration page

The role is chosen when inviting and changed in Administration → Members. An editor prepares a workflow, tests it, then asks an administrator to publish it: the Publish button stays visible to them, greyed out, with that reason.

Shared mailboxes

A service mailbox is connected like any mailbox, by the administrator, from the Mailboxes page (Gmail, Microsoft 365 or IMAP). They then share it from Administration → Shared mailboxes, and choose, member by member, who has access to it. Administrators have access by default.

Having access to a shared mailbox means:

• seeing it in webmail, reading its threads and writing from it;
• handling its drafts in Review;
• seeing its runs in Activity;
• for an editor, choosing it as the watched or sending mailbox of a team workflow.

Without access, the mailbox does not exist for the member: it appears nowhere. Disconnecting, deleting, sharing or making a shared mailbox personal are administrator actions. A personal mailbox stays visible to its owner only, administrators included.

Team Review and activity

A draft produced on a shared mailbox appears in the Review of everyone who has access to it. One decision is enough: the first person who sends, edits, discards or snoozes the draft handles it for everyone; whoever comes next reads “This draft has already been handled by Camille”. The sending log keeps who decided.

In Activity, administrators and editors see every run of team workflows; a member sees those of the mailboxes opened to them, and those that touch no mailbox (schedule, webhook). A team workflow’s failure is notified to administrators and editors — the people who can fix it.

Traceability

Every workflow keeps who created it, who last changed it and who published each version. The audit log (Administration → Log) records changes of role, of a workflow’s scope, of a mailbox’s scope and of its access.

Migrating an existing instance

An instance installed before team workflows keeps its workflows and mailboxes personal. The operator moves them to the team with the instance’s command line, always starting with a dry run:

node dist/cli.js workflows:scope --to organization --import-prefix ps- --dry-run
node dist/cli.js workflows:scope --to organization --import-prefix ps-
node dist/cli.js mailboxes:share --address sales@example.com --members mary@example.com,paul@example.com

workflows:scope selects with --all, an import key prefix (--import-prefix) or an owner (--owner); mailboxes:share shares a connected mailbox and adds access without removing any. Both can be run again without side effects.