Process modelling guide

How to model a business's processes top down: a process map first, then a process chain for each area, then a process flow for each process. One example runs through it, a bank's contact centre. New to Twiggy Modeller? Read this once, then open the demo (Dashboard › Explore the demo) and try each step.

Words we use· three diagrams, and the things in them

Step through the words, or click any part of the picture: it lights up with what it connects to.

1. Process map: all the work the business does

The catalogue of every process the business runs, grouped into enterprise processes and the process areas inside them. No flow and no lines: just what is done and where it belongs. Being on the map is what puts work in scope.

New model › Process map, or type it as an outline.
It holds enterprise processes and process areas.

Diagram	What it shows	Opens from
Process map	Every process the business runs, as a catalogue: enterprise processes, with the process areas inside them	New model
Process chain	One process area: its processes, and which ones work together	A process area on the map
Process flow	One process: its steps, roles, decisions and hand-offs	A process on the map or in a chain, or a sub-process step

Thing	What it is	Example
Enterprise process	A top-level box on the map: a stage of work end to end, or work that steers or supports it	Serve customers
Process area	A group of related processes inside an enterprise process. Areas can hold areas	Manage contact centre
Process	One end-to-end piece of work, from a trigger to an outcome	Perform first-line support
Sub-process	A step in a flow that has a flow of its own	Diagnose the issue
Hand-off	Where one process passes work to another: an end of one is a start of the next	Escalated to second line

The idea: three distinct levels of modelling, top down

Good enterprise models are built from the top. You agree what the business does before anyone draws how a single task is done, so every process flow has a place, neighbours it works with, and an owner. Model the way people read: from the big picture down, one level at a time, and only as deep as a decision needs.

The process map is the catalogue of every process you run: if a process isn't on it, nobody can find it, own it or join it up. The process chain shows how the processes of one area work together. The process flow shows how one process is done.

Give every process area an owner. The areas inside your enterprise processes are where accountability sits: the person who owns Manage contact centre answers for the processes in it, their sign-off and their reviews. Twiggy Modeller is built for this: each area on the map carries its owner, and whole sections of the repository can go into an owned folder, so that person approves every change in it.

Three levels of modelling, top down. The process map says what the business does. A process chain says which processes in one area work together. A process flow says how one process is done, by whom, step by step.

You never set levels. Twiggy Modeller counts how deep each item sits from the top of the process map, and shows it as a small number where it helps (for example in the explorer and in reports). Different parts of the business can go to different depths: a simple area may hold processes straight away, a large one may need areas inside areas.

1. Start with the process map: define all the processes in your scope

Start by listing every process in the scope you are modelling, at the top level. For the whole enterprise, these are the enterprise processes: the stages that take your customer from need to outcome, end to end, usually four to eight (the value chain). For one organisation or division, they are its high-level process landscape: the handful of things that unit does. Either way the method below is the same. Add the processes that steer them (risk, strategy) and support them (people, technology, finance). Name every box as work done, a verb and an object (Serve customers), never a department (Operations), a product (Cards) or a system (CRM).

Starting with one division is fine. But in a true enterprise repository, every process eventually joins up to one enterprise value chain, so name and shape your top boxes as if they will one day sit under it.

A process map for a bank. The dark headers are its enterprise processes, end to end from the customer's point of view, with the ones that steer and support them; inside each, its process areas. Every box is named as work done. A green dot means it already opens a chain or a flow.

In Twiggy

New model › Process map. Type the processes as an outline: Enter adds the next one, Tab puts it inside the one above. Drag boxes to reorder or nest them. Unsure whether something belongs? Mark it unconfirmed (right-click › Unconfirmed (?)) and keep going. Give each process area its owner in Details.

2. Break each one into process areas

Inside each enterprise process, add its process areas, and areas inside those where an area is large. Aim for five to nine under each parent. They should cover the parent completely and not overlap. Stop when a box is one team's end-to-end piece of work with a clear start (a trigger) and a clear end (an outcome): that is a process, and it gets a process flow.

In Twiggy

Right-click a box on the map › Add child process › As a child to break it down, or › Add child view › Flow view when the box is one process. A box with processes inside it is an area: it never gets a flow of its own, its processes get one each. The Sign-off and coverage lens (View › Lens, above the map) shows which processes have a flow, which are signed off, and which are still only names. Show and Compact help when the map grows.

With the AI: ask it on the map to add an area (“add Originate personal loans beside Originate SME loans, reuse where you can”) and it outlines the processes inside it too, marked unconfirmed, reusing a process only where it is truly the same one. Then it offers to draft the flow of one of them.

3. See how an area works: the process chain

A process map shows what exists, not how processes work together. A process chain does that for one area: its processes in their natural order, and a line wherever work passes between two of them, including to processes in other areas. A chain deliberately leaves out the logic: no decisions, no events, no routes. The contact centre's four support processes pass work to each other and to billing, complaints and technology in dozens of ways; in their flows that is dozens of lines, in the chain it is one line per pair.

A process chain of Manage contact centre. Its processes in their natural order, inside the dashed line, and the processes elsewhere they work with, outside it. A line means work passes between two processes, in either direction and however often: the routing and decisions live in each process flow. A purple dot means that flow is signed off.

In Twiggy

There is no separate chain to create: an area's chain is the processes inside it. Right-click a process area (Manage contact centre) › Open chain view. Its processes appear in order, connected wherever their flows hand over to each other, so the chain stays true as the flows change. Modelling top down, connect processes yourself with Connect (or right-click › Connect to): those lines show dashed until a hand-off between their flows confirms them, and amber if both have flows and neither hands over to the other. Turn on Show direction to see which way work goes. The chain glyph on an area on the map opens its chain too.

4. Model each process as a process flow

A process flow is where the work becomes visible: who does what, in what order, with which decisions. Keep each flow to one page, around 5 to 15 steps. Its start and end events set its boundary: what starts it, and each distinct way it can finish, with hand-offs to the processes before and after it.

Going past 15 steps? Before reaching for sub-processes, ask whether you are describing two processes: one that finishes and hands over to another (taking an order, then fulfilling it). If so, split it into two flows joined by a hand-off, and add both to their process area, where its chain shows them connected.

The process flow of Perform first-line support. One trigger to start, steps named verb + noun in the lanes of the roles that do them, decisions as questions with labelled paths, and an end event for each distinct outcome. The escalation hands over to Perform second-line support (the arrow in the circle): the process chain above shows that hand-over as one line.

In Twiggy

Double-click a process on the map or in a chain to open its flow, or right-click › Add child view › Flow view. Fill in its scope card at the top of Details (purpose, owner, customer, measures), or let the AI interview ask for it first. Then Describe it to the AI: tell it the process in your own words and it draws as you talk, asking about what is missing. Or build it on the canvas: T task, D decision, E event, Enter to rename. Link start and end events to neighbouring processes with Comes from and Hands over to: these hand-offs are what draw the lines in the chain.

5. Drill down only where it pays: sub-processes

Most steps don't need more detail. Turn a step into a sub-process when it hides exceptions, several systems or controls that matter for risk or automation, or when a different team owns it. Its flow inherits its boundaries from the step: it starts where the step starts and hands back where it ends.

Drill down only where it pays. When one step hides real complexity (exceptions, systems, controls), decompose it: the step becomes a sub-process with its own process flow, whose start and end events hand over from and back to the steps around it.

In Twiggy

Right-click the step › Add child view › Flow view. Its new flow opens, with its start and end events linked to the steps around it.

6. Enrich: systems, risks, controls and your own properties

Once the flow is right, add what makes it useful beyond the picture: the systems each step uses, the risks it carries and the controls that treat them, the requirements it meets, and the properties your organisation tracks (channel, volumes, automation potential). Define each role, system, risk and control once and reuse it everywhere, so a question like “where is this control performed?” has one answer.

In Twiggy

Keep roles, systems, risks and controls in a library: lanes pick their role from it, and you drag the rest onto steps. View › Lanes by › System (or any of your list properties) to model straight into the systems each step uses: drop a step in a lane to set it. Admins define your own properties in Administration › Properties. Then use a lens (View › Lens: risk rating, systems, owner or any of your properties) to colour a flow or the whole map by them.

7. Review with the people who do the work, then sign off

A model is only as good as its review. Ask the people who do the work to check the lanes they know, fix what they find, and then have the process owner sign it off. Signed-off flows are locked; changes go into a new revision while readers keep seeing the signed-off one.

In Twiggy

⋯ › Review and sign-off. Reviewers get a private link, with no account needed, and can be asked about just their lanes. Put signed-off content in an owned folder so its owners approve every change, and set review cycles by risk in Administration › Sign-off and review.

Conventions

Element	Convention	Good	Avoid
Enterprise processes, areas, processes and steps	Verb + object, sentence case	Assess credit risk	Credit risk, Risk team, Process 4
Events	Thing + what happened (past tense)	Loan approved	Approve loan, End
Decisions	A short question	Fixed?	Check, Decision 1
Paths out of a decision	The answers, each labelled	Yes / No: escalate	Unlabelled lines
Lanes	Roles from the roles library, not people or departments	Agent, Credit analyst	Jane, IT
Work a system does on its own	An automated (service) step in the lane of the role that owns the system, with the system attached. To see it the BPMN way, view the flow by system	Score the application (service, Credit decision engine) in Credit	A lane called System
Starts and ends	They set the boundary of the process. One start per distinct trigger, one end per distinct outcome, and intermediate events for waits and milestones in between	Contact received; Contact resolved, Escalated	One “End” for everything
Size	Five to nine per parent on the map; 5 to 15 steps per flow		A 60-step flow
Uncertainty	Mark it, don’t guess	Review documents (?)	Invented steps

Why not a System lane? BPMN often gives a system its own lane, and that is a fair reading of who does the work. We recommend the owning role instead: lanes are what people review and sign off, and someone is accountable for what a system does in their process. Systems are changed and replaced; responsibility stays. You lose nothing: View › Lanes by › System shows the same flow with a lane per system, and BPMN export keeps the roles.

Best practice

Scope before steps. For every process, agree its purpose, trigger, outcomes, customer and owner before drawing it. Twiggy Modeller's AI interview asks for these first.
Model as-is first. Capture how work is done today before designing how it should be. Improvements need a baseline everyone agrees with.
Interview the doers, not only the managers. The exceptions live with the people who handle them. This is the heart of Twiggy Modeller: interviewing the people who do the work, with the AI, and having them review and sign off what they told you.
One level at a time. Don't mix enterprise boxes and keystrokes on one page. If a step needs detail, make it a sub-process.
Hand-offs are the joins. Most problems sit between processes. Make every hand-off explicit, so the end of one process is the start of the next; the chains then draw themselves. Do it well and Twiggy Modeller pays you back: it suggests the neighbouring processes to link to, finds matching hand-offs across models, and flags connections on the map that the flows don't back up.
One model, many views. A flow is not one picture: look at it by role, by system, with no lanes, or by any of your own list properties (channel, region), and colour it with a lens. Each view shows a different gap, such as a step with no system or a channel nobody covers. You can model in any of them, and Twiggy Modeller lays every one out for you, so you never spend time moving boxes.
One name for one thing. Agree names for processes, roles, systems and risks, and reuse them from the libraries. Synonyms make a repository unsearchable.
Model for a purpose. Know the question the model will answer (risk and controls, automation, onboarding, an audit) and stop at the depth that answers it.
Keep it alive. A signed-off flow with an owner and a review date stays true. One without either goes stale within a year.

Common mistakes

Departments or systems as processes (Operations, CRM). Model the work they do.
Systems as lanes in the role view. Lanes are roles; give steps their systems and view the flow by system.
Routing logic in a chain. A chain shows that two processes work together; how and when belongs in their flows. If you clearly need decisions or routes between the boxes of a chain, you are modelling at the wrong level: model that logic one level down, in a process flow (perhaps the chain's boxes are really the steps of one process).
Giving every exception the same weight as the main path. Show the exceptions that matter at this level, but keep the main path easy to follow: it should read top to bottom without detours. Rare exceptions that only add noise are better left to the review, or to the step that handles them.
Decisions without labelled paths, or one end event for every outcome.
Drawing flows before the map: you end up with orphan flows that nobody can find or join up.

What Twiggy Modeller does for you

You want to	Twiggy Modeller helps with
Get a first draft fast	The AI interview: describe a process in your own words and watch it being drawn; it asks for the scope first, then the steps, names them consistently and marks what it inferred with (?)
Lay out the business quickly	Typing the process map as an outline
See how an area works	Process chains drawn from the hand-offs in its flows, always up to date
Join processes up	Hand-off pickers that suggest the neighbouring process first, AI matching across models, and connection lines on the map
Go deeper without losing the thread	Make a step a sub-process, with its boundary events linked for you
Reuse instead of retyping	Libraries of roles, systems, risks, controls, rules and requirements, dragged onto steps
Model the way you think	Edit a flow by role or by system: drag a step into a lane to set it
Capture what your organisation cares about	Your own properties, defined once by an admin, captured on steps and lines
See patterns	Lenses: risk, sign-off and coverage, systems, owner, or your own properties, on flows and maps
Get it checked	Review rounds by link, lane by lane; sign-off by owners; review cycles by risk; version history
Use it elsewhere	BPMN export and import, pictures of any diagram, presentation mode

Questions about a specific screen? See the Help centre.