Cross-functional work inside the company follows the organisation. A collaborative app starts there: you define the functions and their levels, attach a screen to each level, assign the people at each level, and then write the criteria that start the flow and move it between levels.
A hierarchy is people-centric: the data and the actions follow the people, so the hierarchy comes first.
A collaborative app begins with a hierarchy definition: the functions that take part and the levels inside each one. A function such as procurement may have three levels, buyer, category lead and chief procurement officer; finance may have two; legal one. Each level records how many parent levels and child levels it has, so the platform knows where a flow goes up and where it fans out.
A process can use several hierarchies for different purposes: the organisation chart for approvals, a project hierarchy for tracking, a functional hierarchy for escalations and notifications. Each hierarchy captures organisation-and-person combinations, so the same person can sit at one level in one hierarchy and at another level in a second.
The hierarchy is data, kept with the app definition and versioned with it. When the organisation changes, the hierarchy changes, and running instances keep the hierarchy version they started on.
| Hierarchy | Used for | Example |
|---|---|---|
| Organisation hierarchy | Approvals that follow reporting lines | Capital request: plant, division, group |
| Functional hierarchy | Escalations and notifications inside a function | Late invoices: AP clerk, AP lead, controller |
| Project hierarchy | Task assignment and tracking on a project | New product introduction: workstream leads, launch lead |
| Approval hierarchy | Sign-offs by value band | Journal entries: preparer, reviewer, approver |
| Parallel hierarchies | Several functions deciding side by side | S&OP: demand, supply, finance, executive |
Each level has a specific view of the data.
Every level gets a screen, composed from the same components as any other screen: grids, fields, charts, buttons and pop-ups. What differs is the view. For approvals the data is attached at the lowest level and each higher level sees the same case with less detail and a decision; for task assignment and tracking the data is attached at the higher levels and each lower level sees its own share.
A screen at a level reads through data handlers, so a buyer's screen lists the live purchase order lines of their purchasing group, and the category lead's screen aggregates the same rows by supplier. The access rules of the source apply at read time, and the level's own filter narrows the view further.
Screens can be generated from the hierarchy and the handlers: point the studio at the objects and the levels, and it drafts a screen per level with the fields each level decides on. Screens covers the components and properties in full.
| Level | Sees | Decides |
|---|---|---|
| Buyer (Procurement L1) | Their own contract renewals: consumption against target, prices against the last orders | Renew, renegotiate or let lapse; proposes |
| Category lead (L2) | All renewals in the category, ranked by value and risk | Approves proposals below 1,000,000; returns with a note |
| CPO (L3) | Renewals above 1,000,000 and the ones returned twice | Final approval |
| Controller (Finance L1) | The budget line each renewal draws on | Confirms budget cover, in parallel with L2 |
| Counsel (Legal L1) | The clauses that changed since the last version | Approves clause changes, in parallel with L2 |
Alternates, delegates and outside parties are part of the definition.
People are assigned to levels, and a person created at a level is given their parent-level and child-level users as part of the creation, so escalation and fan-out have somewhere to go from the first day. Each level can name an alternate who acts when the primary is away, and a person can delegate to a named colleague for a stated period; the log records both names on every step taken under a delegation.
Outside parties can hold a level. A supplier level under a category, with portal screens, lets the supplier's planner and account manager take part in a forecast and commit cycle, seeing only the parts and orders the access policy allows. The Supplier collaboration portal app is built this way.
One rule per collaboration activity per level, written in the expression editor and tested on live rows.
The rules of a collaboration are meta data: for each activity they say which prior action triggers it, which function and level it happens at, which level comes next when the rule holds, what type it is (approval, escalation, task assignment or tracking), the rule that decides success, proceed or return, the table that holds the run-time data, the filter that identifies the rows, the screen at that level and how long the action stays active. The running instances are the run-time data: the traces of each activity, closely referencing the rules that produced them.
| Activity | After | Function · level | Next level | Type | Rule | Screen | Active for |
|---|---|---|---|---|---|---|---|
| RENEW-1 | start | Procurement · L1 | L2 | Task assignment | contract.valid_to <= today + 90 | S01 | 5 working days |
| RENEW-2 | RENEW-1 | Procurement · L2 | L3 if value > 1,000,000 else done | Approval | proposal present and note present | S02 | 3 working days |
| RENEW-2F | RENEW-1 | Finance · L1 | done | Approval | budget cover confirmed | S04 | 3 working days, in parallel |
| RENEW-2L | RENEW-1 | Legal · L1 | done | Approval | clauses reviewed | S05 | 3 working days, in parallel |
| RENEW-3 | RENEW-2 | Procurement · L3 | done | Approval | value > 1,000,000 | S03 | 5 working days |
| RENEW-E | any | parent level | same | Escalation | clock expired | same | until acted |
The trigger criterion starts the flow. It can be a condition on the data (contracts expiring within 90 days), a calendar (the first working day of the month), or a person at a level starting it by hand. The flow criteria then decide, at each level, whether the activity succeeded, proceeds to the next level, returns to a lower level or ends. Rules are written with screen, app, global and system variables and constants, in the expression editor, and tested against the live rows they will select.
Time limits belong to the rule: each activity stays active for a period, after which the rule for that level decides what happens: escalate to the parent level, pass to the alternate, or return to the requester with a note. The period can be a fixed date range, a number of days after the last action, or a bucket of the calendar such as working day 5.
Number of levels, alternate approver at each level, delegation, series or parallel, a time limit per level and an escalation user. Data is attached at the lowest level and moves up.
A record has an owner; the owner assigns it to one or several people; they finish in sequence or in parallel; each assignment has its own time limit.
When a clock runs out, the parent level receives the case with the full context: what was asked, what happened, how long ago.
Higher levels see the progress of every instance below them: step, age, owner, next clock.
Inform a level, a function or everyone, with a structured message on Slack, Teams or email, and a link into the workbench.
Threaded discussion anchored to the case, with reactions, part of the record.
A level can grant a lower level a permission for a period, for example to release a block, and the grant is logged.
A handshake between functions or companies: each party signs the same version of the case, and the case closes when all have signed.
Surveys collected at a level, rewards or incentives assigned by a rule, and measures shown per level as the flow runs.
The catalogue entry has every screen, rule and clock.
As many as the organisation needs; three is common and seven has been configured. The hierarchy records parents and children per level, so depth is free at run time.
The person is retired from the level, their open steps pass to the alternate, and the log keeps their name on the steps they took. The hierarchy version changes; running instances finish on the version they started on.
Yes. The first person in the group to act takes the step, and the log records who it was.
Yes, and it usually does. A capital request, a budget variance review and a journal approval can share one organisation hierarchy, each with its own screens and rules.
Through the access policy of the source system, applied when the data handler reads, plus the scope filter of the level. A supplier at a level sees only the parts and orders that belong to it.
Bring one process and the systems it touches. In the first session we register the data handlers, draw the levels or the lanes and run the first screen on your live rows.
