Business units and hierarchy

A business unit identifies an operating part of your tenant, such as a head office, branch or shop. It is different from a user's role and from an inventory warehouse's stock configuration.

Form fields

Field	Meaning and current form limits
Code	Required, up to 50 characters; creation trims/uppercases it; disabled on edit
Name	Required, up to 150 characters
Type	Head Office, Branch, Shop, Warehouse, Office, Online Store, Franchise, Factory, Sales Office or Care Facility
Parent Business Unit	Optional parent in the tenant hierarchy
Legal Name	Optional, up to 200 characters in this form
Tax Number	Optional, up to 100 characters in this form
Status	ACTIVE or INACTIVE
Active	Separate activity value on edit; review the actual saved state

The form currently exposes Legal Name and Tax Number. This documents the existing screen; it does not introduce a second identity model. Party owns shared identity/contact information in the application architecture.

Create a branch

1. Open Organization → Business units.
2. Choose the available create action.
3. Enter BHS-NORTH, North Branch and Branch.
4. Select BHS-HQ as Parent Business Unit if appropriate.
5. Complete approved identity/status values and create the unit.
6. Open its details and verify the saved values.
7. Add addresses/contacts where needed, then assign staff access separately.

Hierarchy review

Open Business unit hierarchy to inspect parent/child placement. Do not create a cycle: HQ cannot become a child of North while North is already under HQ. The form removes the current unit from parent choices; the service also validates the ancestor chain.

A parent relationship is not a promise of inherited operational access to every child. Assign explicit user-unit access and confirm the relevant module's scope rules. Care also has facility/caseload visibility controls beyond these general grants.

Change, deactivate or delete

Use the permitted edit action and verify both Status and activity information. Deactivation affects availability in active-unit choices; it does not move old transactions or automatically reassign staff to another branch. Review user primary units and open operational records before changing availability.

The current business-unit delete service deactivates the unit and its linked Party rather than physically erasing the unit. Treat the action as a significant availability change and review related records and staff scope first. If refused, resolve the reported dependency through its owning workflow. Do not recreate the same unit under another code to escape a restriction.

Parent removal limitation

The current update service changes the parent only when a non-null parent ID is supplied. Clearing a parent selector is therefore not evidence that the saved parent was removed. Reload the detail and hierarchy to verify. If detaching a unit is required and the old relationship remains, report the limitation through support rather than repeatedly saving a blank value or creating a duplicate unit.