Set Up Your Organisation

Goal

Describe your organisation — its units, who works in each one, and who does which kind of work where — so that business processes can route work to real people, and so that record access rules like "my unit and everything below it" have a tree to measure against.

Prerequisites

• An environment. Every environment gets the organisation tables and the Organisation app when it is created; there is nothing to install.
• Your people already exist as users. Units hold the people your tenant has, so add users first if you have not.

Where it is

Open the Organisation app from the app launcher in the Platform Shell — not the Admin Control Center, which is where users, roles and teams live tenant-wide. The organisation belongs to an environment, because you may want to rehearse a reorganisation in a Test environment before it is true in Production.

The app has four pages:

Page	What it holds
Units	The organisational chart: each unit, the unit above it, its type, and its head
Users	The environment's users, and which unit each of them is in
Teams	Named groups a record can belong to, each sitting in a unit
Process Roles	Who does which kind of work, in which unit

Steps

1. Build the unit tree

Units opens as a tree, not a list. Each unit sits under the one above it, so you read the shape of the organisation rather than a column of parent names. Select a chevron to open a unit, or use the arrow keys — right opens, left closes, and left again on a closed unit moves up to its parent. Only the part you have opened is loaded, so a chart with thousands of units opens as fast as one with six.

Click a unit and its details open beside the chart — the table's own form, saved exactly as it is on the record's own page. The chart stays where it is, so you can move around it and keep reading. Drag the divider between the two to give one side more room; the width is remembered for this screen. On a narrow screen they take turns, with a way back to the chart.

Search the chart with the box at the top of the tree pane. Matches appear under the units they sit in, so two branches with the same name are told apart by what is above them — and every line is clickable, the chain included. Choosing a result puts you back in the chart with that unit selected, which is where you were trying to get to. Escape gives the chart back with whatever you had opened still open.

The search matches a unit's name. If more match than fit, it says so — narrow the search rather than scrolling.

The people in each unit are in the chart with it

Under each unit, below its sub-units, are the people who sit in it — each with their own picture in place of the unit glyph, or their initial where they have no photograph. That answers "who is in this branch" in the chart itself, instead of leaving it for the Users page and filtering by hand.

Selecting a person shows their card beside the chart rather than a form: a chart is where you read an organisation, not where you edit an employee. Open Users to change one. Searching finds people as well as units, each shown under the unit they are in.

What a chart draws is part of the view: which tables hang under which, what each kind of row is called, its icon or picture, and whether choosing one shows a form, a card, or nothing at all. The View Designer cannot author that yet, so today it is set in the view's definition — the Units view ships with units and their people already described.

Showing one branch instead of the whole organisation

Select a unit and press Show only this branch (the crosshair beside the search box). The chart re-opens with that unit at the top, and a trail above it says where you are: select a step in the trail to climb back out, or All for the whole organisation. While the chart is focused, the search looks inside that branch — a result you could not then see would be no use.

Where the chart is focused travels in the link, so you can send somebody "the Tehran province, opened at this unit". It is not part of the view's definition, and that is deliberate: a unit that exists in your Test environment is not the same record in Production, so a focus baked into a solution would point at nothing after the first import.

Double-click a unit to open its record page over the whole window.

The address bar follows the selection, so a link you send opens the chart on the same unit you were looking at.

1. Select New.
2. Enter a Name, and leave Parent Unit empty for the top of your organisation.
3. Set a Unit Type — Branch, City, Province, Hospital, whatever your organisation calls its levels. This is your own vocabulary, not a list we ship.
4. Set a Manager: the person who heads this unit.
5. Save, and repeat, this time choosing the unit above each new one as its Parent Unit.

Nothing forbids more than one top-level unit — an organisation with two legal entities has two.

2. Put people in units

Open Users, open somebody, and set their Organisational Unit. A person sits in one unit. That single fact is what every unit-scoped access rule and every "who is in this branch" question is answered from.

3. Say who does what, where

Open Process Roles and select New. Each row is three things: a User, an Organisational Unit, and a Role.

Read a row as "this person does this kind of work in this unit". A branch's approver, the HR person for a region, the reviewer for head office.

The unit does not have to be the person's own. A regional approver sitting in head office is an ordinary arrangement, and it is exactly what three columns rather than two exist for.

Why a process needs this

When a business process reaches a step assigned to a role — role("Manager"), say — the engine asks: who holds "Manager" in the unit this run is happening in? The answer comes from the Process Roles rows and nothing else.

If there are none, the answer is nobody. The run stops with Waiting on: Nobody, and no amount of correct process design will change that — the process is fine; the organisation has not been described yet.

The same table is what escalation climbs: when nobody holds the role in a unit, the engine walks up the Parent Unit chain, asking at each level, until it reaches a unit of the type the process says to stop at.

A process role is not a permission

This is the one thing worth being clear about, because both are called roles:

	A process role	A security role
Where it is set	The Process Roles page, in an environment	The Roles page in the Admin Control Center, tenant-wide
What it decides	Who gets sent this kind of work	What somebody is allowed to see and do
What it grants	Nothing	Table permissions, and the scope they are held at

Giving somebody a process role does not widen what they can see. If they are to open the records a task is about, they need the access for it as well — see Grant a role access to records.

In a development environment, it is already filled in

A development environment created with sample data on arrives with an organisation already in it: a head office, two regions, four branches, your people placed in the branches, a head on every unit, and process role assignments for everybody. This exists so a process can be run the minute the environment is created rather than after half an hour of typing.

It is sample data. Rename it, re-shape it, or delete it and enter your own — and note that production environments are never given one.

What to check when work goes nowhere

• Waiting on: Nobody — nobody holds that role in that unit. Add a Process Roles row, or check the run is happening in the unit you think it is.
• The wrong person gets it — look at the unit on the assignment rows, not just the role.
• An escalation stops too early or climbs too far — check the Unit Type values along the parent chain; that is what a process's "stop at" setting matches on.