Designing Approval Slots with Users, Roles, and Teams

Learn how the Human node's approval slots and atoms decide who must sign off, how a single approver can satisfy a slot, and why every slot has to be satisfied before a workflow continues.

Overview

When you pause a Spojit workflow for human sign-off, you add a Human node and tell it who is allowed to approve. You do that through Approval slots, the only required setting on the node. A slot is a single sign-off requirement, and each slot is filled with one or more atoms. An atom names a specific approver: a User, a Role, or a Team. This small model lets you express everything from "anyone on the finance team can approve" to "both a manager and the workspace owner must approve" without writing any logic.

The mental model has two rules. Within a single slot, the atoms are an OR: any one atom satisfies the whole slot. Across multiple slots, the rule is an AND: every slot must be satisfied for the approval to complete and the workflow to continue. Designing approvals is therefore a matter of deciding how many slots you need (how many independent sign-offs) and which atoms go in each (who can provide each sign-off). This guide breaks down the slot and atom model in detail so you can build the exact approval shape your process needs.

Before You Start

You need a workflow open in the Workflow Designer with a Human node placed on the canvas. See the guide on using Human approval nodes for the full node walkthrough.
The Users, Roles, and Teams you plan to reference must already exist in your workspace. Create teams under Settings and invite people before you wire them into a slot.

The Slot and Atom Model

Open the Human node's properties panel and find the Approval slots section. Each slot is a row that holds one or more atoms. You build an approval requirement by adding slots, then adding atoms to each slot.

An atom is one of three kinds:

User: a single named person in your workspace. The slot is satisfied if that exact person approves.
Role: anyone holding a given role (Owner, Admin, or Member). The slot is satisfied if any person with that role approves.
Team: anyone who belongs to a named team. The slot is satisfied if any member of that team approves.

The two combination rules are what make slots expressive:

Atoms within a slot are OR. Put a User atom for Dana and a Team atom for "Finance" in the same slot, and either Dana approving or any Finance member approving will fill that slot.
Slots are AND. Add a second slot, and now both slots must be satisfied independently before the approval completes. This is how you require two distinct sign-offs.

How Roles Cascade

Role atoms are not isolated. Roles in Spojit cascade by seniority: Owner outranks Admin, and Admin outranks Member. When a slot contains a Member role atom, anyone with Member, Admin, or Owner can satisfy it, because the senior roles inherit the ability to act in place of the junior one. A slot that names only the Owner role, by contrast, can only be satisfied by an Owner.

The practical effect: name the lowest role you are willing to accept. If "any team member is fine," use a Member role atom and your Admins and Owner can still approve. If you specifically need senior oversight, name Admin or Owner so juniors are excluded. For a full breakdown of what each role can do, see the roles and permissions guide.

Worked Examples

Anyone on a team can approve (one slot, one Team atom). Add a single slot and place one Team atom for "Operations". The first Operations member to respond satisfies the slot and the workflow continues. This is the simplest single-sign-off pattern.

Either a specific person or a fallback team (one slot, two atoms). In one slot, add a User atom for your finance lead and a Team atom for "Finance". Because atoms within a slot are OR, the named lead can approve directly, but if they are out, anyone on Finance can cover. One sign-off is still all that is required.

Two independent sign-offs (two slots). Add slot one with a Team atom for "Finance" and slot two with a Role atom for Owner. Now a Finance member AND the workspace Owner must both approve. Because slots are AND, the workflow waits until both slots are satisfied. The two approvers can act in any order.

Tiered sign-off for high-value items. Pair the Human node with a Condition node upstream so that small requests route to a one-slot Human node and large requests route to a two-slot Human node. The slot model itself does not branch on amount; you express the threshold in the Condition and design each Human node's slots accordingly. See configuring approval requirements for the surrounding settings.

What Happens When the Approval Resolves

Once every slot is satisfied, the approval is Approved and the workflow continues, with the node output { approved: true, approvalId, outcome: "APPROVED" } available to downstream nodes. If any approver rejects, the outcome is APPROVAL_NOT_APPROVED and the workflow halts at that node. A timeout (set via Timeout (minutes)) is treated as a rejection and also halts the run. Spojit does not support a separate "on reject, do X" branch from a Human node, so design your slots to gather exactly the sign-offs you need rather than relying on downstream reject branching. Approvers act in the Approvals inbox at /approvals, on the dashboard widget, and via the menu badge.

Tips

Keep slots to the minimum your process truly requires. Every extra slot is another person who must respond before the workflow moves, which directly affects how fast the run completes.
Prefer Team atoms over individual User atoms for coverage. A team absorbs vacations and turnover, whereas a named user becomes a bottleneck when that one person is unavailable.
Name the lowest acceptable role in a Role atom and let the cascade include seniors. Reaching for Owner when a Member would do simply narrows your pool of approvers.
Use Miraxa, the intelligent layer across your automation, to scaffold the node ("Add a Human node that requires sign-off from the Finance team and the workspace Owner"), then fine-tune the exact atoms in the properties panel.

Common Pitfalls

Confusing OR and AND. Putting two people in the same slot means either one can approve; putting them in separate slots means both must approve. If a single sign-off is unexpectedly waiting on two people, you have split atoms across two slots by mistake.
Forgetting the role cascade. A slot with only an Owner atom cannot be satisfied by an Admin or Member, so if your Owner is away the workflow stalls. Add a Team or lower-role atom as an alternative within the same slot if you want a fallback.
Referencing a team or person who is not in the workspace yet. Atoms can only point at existing Users, Roles, and Teams, so create and invite them first. See creating and managing teams.
Expecting a reject path. Rejection and timeout both halt the workflow at the Human node. If you need different handling for "not approved," structure the work so that halting is acceptable, or gate the Human node behind a Condition rather than trying to branch after it.