Business Processes

What Is a Business Process in ArchRepo?

A Business Process is a repeatable sequence of activities that the business performs in order to achieve a defined outcome. At the level of the architecture repository, the focus is on what the business does — not how the solution implements it. Business Processes describe the operating model: the activities, information flows, and outcomes that the solution is designed to support.

Business Processes in ArchRepo are linked to the information they work with, the outcomes they contribute to, and the applications that support them — building a connected model of business operations and their relationship to the technical solution.

Process Hierarchy

Business Processes can be decomposed into sub-processes, enabling a structured view from high-level process areas down to operational detail.

The Level field classifies each process in the hierarchy:

Level	Typical meaning
0	Enterprise or value chain level — the highest-level view of the business’s activities
1	Value stream or domain level — major process areas (e.g., Order to Cash, Procure to Pay)
2	Operational process level — specific processes within a domain (e.g., Raise Purchase Order, Approve Invoice)
3+	Task or step level — detailed activities within a process

The Contains relationship links a parent process to its sub-processes, building the hierarchy:


Order to Cash  (Level 1)
├── Receive Order  (Level 2)
├── Fulfil Order  (Level 2)
│   ├── Pick and Pack  (Level 3)
│   └── Ship Order  (Level 3)
└── Invoice Customer  (Level 2)

There is no required depth — model to the level that is useful for the solution context.

Information Flow

Three relationship types describe how Business Information moves through a process:

Relationship	What it means
Receives	Information that enters this process as input — provided by a preceding step, system, or external party
Generates	Information that this process produces as output — a record, report, or decision created by the activity
Uses	Information that this process references during its execution, but does not receive or produce (e.g., a price list consulted during order processing)

Together these three types build a complete picture of a process’s information flows. They also feed directly into the Business Processes v Information collection view, which maps all processes to all information items.

Process Triggering

A Business Process can trigger another process, allowing you to model sequential or event-driven process flows. For example:

“Receive Order” triggers “Credit Check”
“Invoice Approved” triggers “Schedule Payment”

Use the Triggers relationship to capture these dependencies. This helps identify where delays in one process cause downstream impact, and where automation or integration can reduce handoff time.

Transition States

Business Processes support Transition States, which track how a process evolves as the solution is delivered. This is particularly useful for projects that involve business change as well as technical delivery.

Use Transition States to represent how each process changes across solution phases:

As-Is — how the process operates today, before the solution is in place
To-Be — how the process will operate once the solution is delivered
Phase 1 / Phase 2 — if the solution is phased, show which processes are affected in each phase

This makes the business change impact of the solution explicit and traceable — not just what is being built, but what will change in how the business operates.

Collection View

The Business Processes collection includes a cross-reference matrix view:

Business Processes v Information — maps every process to the Business Information items it receives, generates, or uses; a useful completeness check to confirm that all information flows have been identified

Fields Reference

See Business Process Fields for a description of each field and guidance on what to record.