SmartApps Two ways

Two ways to build: from the people, or from the process.

A collaborative app starts with the functions and their levels; a screen is attached to each level, people are assigned to each level, and the flow and trigger criteria are written last.

COLLABORATIVE APP · LEVELS FIRSTProcurementLevel 1screen · usersLevel 2screen · usersLevel 3screen · usersFinanceLevel 1screen · usersLevel 2screen · usersLegalLevel 1screen · usersFlow and trigger criteriaPO value > 250,000 → start at Procurement L1 → L2 → L3; Finance L1 in parallelDefine the functions and their levels, attach a screen to eachlevel, assign the people at each level, then write the criteriathat start the flow and move it between levels.PROCESS APP · LANES AND BOXES FIRSTRequesterBuyerFinanceSupplierRequestscreen · roleCheckscreen · roleDecide?Approvescreen · roleConfirmscreen · rolesubmitted> 10,000approvedDraw the lanes, place the boxes, attach a screen to each box, namethe role that owns each box, then write the criteria on eacharrow. Users join through their roles.any process, any function, inside or across companies
The same four things in a different order. Collaborative apps answer first who takes part and at which level; process apps answer first which steps exist and who owns each one.
11
collaborative app types in the catalogue
catalogue
22
process app types
catalogue
7
data-driven app types, which are process apps started by a criterion on records
catalogue
2
decisions to make before building: who takes part, and what shape the work has
method
5
blocks shared by both: screens, data handlers, actions, variables, the workflow engine
product
The choice

Six questions decide the way to build

Answer them for the process you have in mind. Most processes answer clearly on the first two.

QuestionCollaborative appProcess app
Does the work follow the organisation?Yes: it moves up and across functions and their levels.Partly: it moves between roles, and the roles may sit in several organisations.
Who takes part?People inside the company, placed at a level of a function.Roles inside or outside the company: suppliers, carriers, customers, auditors.
What starts it?A criterion on the data, a calendar date, or a person at a level.A form submitted, a record matching a criterion, an event from a system.
What is the shape?A hierarchy: each level sees its own view and passes the work up, down or sideways.A drawing: lanes, boxes, decisions, parallel paths and loops.
Where is the weight?In the sign-offs: who approved, who escalated, who was informed.In the steps: what was checked, what was written back, in which order.
Typical examplesS&OP cycle, shortage room, budget review, audit findings, change advisory board.Supplier onboarding, warranty claim, engineering change, credit limit change, incident.
Side by side

One process, built both ways

A capital request can be built either way. The difference is what you define first and what the running app looks like.

AS A COLLABORATIVE APPPlantLevel 1: requesterscreen · usersLevel 2: plant controllerscreen · usersDivisionLevel 1: division CFOscreen · usersGroupLevel 1: investmentcommitteescreen · usersa person created at a level is assigned their parent-level and child-level users at the same timeTrigger and flow criteriaamount > 250,000 → Plant L1 → L2 → Division L1 → Group L1
Built from the levels: each level has its own screen on the request and the budget line, the criteria say which amounts reach which level, and the log reads as a chain of sign-offs.
AS A PROCESS APPRequesterControllerDivision CFOCommitteeStartRequestS01Budget checkS02> 250k?ApproveS03DecideS04submittedyes> 1M
Built from the lanes: the same people appear as roles, the budget check is a box with its own screen and a decision, and the log reads as a sequence of steps.
What they share

Underneath, the same five blocks

ScreensComponents in layouts, with properties, validation, unique IDs and actions. A level's screen and a box's screen are the same kind of thing.

Because the blocks are shared, the choice is reversible. A process app that grows into a company-wide review can be rebuilt as a collaborative app by defining the levels and re-attaching the screens that already exist. A collaborative app that needs a supplier's step can add a portal screen in a lane, because a level and a lane both attach screens and people the same way.

The choice is also combinable. A collaborative app can start a process app from one of its levels, and a process app can raise an approval that runs as a small hierarchy. The New product introduction readiness app is a hierarchy per function whose engineering level opens an Engineering change request process when a part changes.

From the catalogue

The app types, by the way they are built

Each entry names its levels or its lanes, its screens, its data handlers and its criteria.

Collaborative apps

Process apps

Data-driven apps

Terms on this page

Collaborative appAn app built by defining functions and their levels first, attaching a screen to each level, assigning the people at each level, and then writing the flow and trigger criteria.
Process appAn app built by drawing lanes and boxes first, attaching a screen to each box, naming the role that owns each box, and writing the criterion on each arrow.
LevelA position in a function's hierarchy, such as buyer, category lead or chief procurement officer. Each level has a screen and a set of people.
LaneA horizontal band in a process drawing that belongs to one role; the boxes in it are the steps that role performs.
Flow criterionA condition, written in the expression editor, that moves a flow from one level or box to the next. A trigger criterion is the condition that starts the flow.
Data handlerA named connection from an app to rows in a system: a federated table, a saved query, a pipeline result, an API or a file. Screens, expressions and decision points use it to read and write.
Questions

Can one app be both?

Yes, by composition. A collaborative app calls a process app from a level, or a process app raises an approval that runs as a hierarchy. Each keeps its own definition and its own log entries, linked by the process ID.

Which is faster to build?

A process app with a form start is usually the fastest: 2 to 4 working days for a production-grade version in the catalogue estimates. Collaborative apps take longer because the hierarchy is defined once and reused: 5 to 8 days, after which each further app on the same hierarchy is quick.

Do both work on live data?

Both read through data handlers, so both show live rows from the systems and both write back through released interfaces.

Which do outside parties use?

Process apps most often, through portal screens in their lane. A collaborative app can include an outside level, for example a supplier level under a category, when the collaboration itself is with suppliers, as in the supplier collaboration portal.

See a SmartApp built on your data

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.