Skip to main content

Step 4 — Swimlane

For the full editor reference, see the Swimlane Editor.

Its Place in Our Scenario

We create two swimlanes, each matching a step in the workflow:

SwimlaneRole(s)Used in which step
maker_laneMakerThe maker's record-creation step
checker_laneCheckerThe checker's approval step
info

A swimlane can hold several roles (e.g. both Editor and Approver). Then a user with any of those roles can pick up the swimlane's task.

Step by Step

1. Add New → New Swimlane

From + Add New, choose New Swimlane. Name the model — usually swimlanes.

Create New Swimlane dialog

Confirm with CREATE → the empty Swimlane Editor opens.

2. Add the swimlanes one by one

The Swimlane Editor is a plain table: each row is a swimlane with two columns — Name and Role. Unlike the other models, a swimlane has no separate detail page; everything is filled in inline.

For maker_lane:

  1. Press ADD NEW at the top right → a new row appears.
  2. Type maker_lane into Name.
  3. Click the dropdown in the Role column → the list of all defined roles (Maker, Checker from Step 2) opens.
  4. Choose the Maker role.

For checker_lane:

  1. Press ADD NEW again for a second row.
  2. Name = checker_lane.
  3. From the Role dropdown, choose Checker.
info

The Role column allows multiple selection. If the same task can be picked up by several roles, tick the boxes next to each role in the dropdown.

3. Save

Click the disk icon in the toolbar, enter a short summary, and confirm with SAVE CHANGES.

Swimlane list — saved

Good to Know

  • A swimlane does not know a user directly at runtime — it only knows roles. At login, the system checks whether any of the persona's roles matches the swimlane's role list; on a match the user sees that swimlane's tasks.
  • The swimlane–workflow link is one-way: the swimlane does not know the workflow; a swimlane is assigned to each User Task in the workflow editor (next step shows this).
  • The same role can be used in several swimlanes, and a user can see tasks from several swimlanes at once — every eligible task lands in their pool.
  • Deleting or renaming a swimlane breaks the User Tasks that reference it. Update the workflow side first.

So Far in Our Scenario

DoneStep
✅ 3 privileges1
✅ 2 roles (Maker, Checker)2
✅ 2 personas (MakerUser, CheckerUser)3
✅ 2 swimlanes (maker_lane, checker_lane)4

The Access Management models are now in place:

WORKFLOW SIDE                                  USER SIDE
(where the workflow assigns) (what the user is authorized for)

swimlane → role ← persona ← user
maker_lane Maker MakerUser (logged in)
checker_lane Checker CheckerUser (logged in)


privilege
submit_record, approve_record, view_record

Next Step

Next we define the Actions — the buttons shown on workflow User Tasks and their privilege control.