Roles and approvals: responsibility inside a connected business

A connected ERP makes information available across departments, but people still have different responsibilities. A salesperson may need to understand an order's delivery position without being responsible for changing warehouse stock. A budget owner may need to approve expenditure without administering every company setting.

Roles and approval rules help express those responsibilities in the system. Their purpose is to make business authority clear and to reduce mistakes that become harder to resolve once transactions progress.

Access and approval solve different problems

Access rights determine what a user is allowed to see or do. Approval determines whether a particular transaction has received the required authorisation. Permission to prepare a request does not necessarily include permission to approve it, and permission to view information does not necessarily include permission to change it.

In DNA, viewing, adding, editing, deleting, voiding, and approving are separate permission checks. Available actions also depend on document state. A transaction can therefore be visible while its editing or processing actions are restricted. This is useful when several people need a common view of the business but only designated people should change a particular record.

Approval rules can add transaction-specific controls. For supported processes, DNA can express multiple approval levels and value thresholds. It also supports responsibility-based routing in certain areas, including department-based purchase requisitions, destination-zone responsibility for stock transfers, and cost-centre responsibility for budgets.

Why the responsible person matters

The best approver is someone who can evaluate the decision, not simply someone with a senior title. A department manager may understand whether requested equipment is needed. A budget controller may understand whether funding is available. A warehouse zone manager may understand whether a transfer destination is suitable.

These perspectives are complementary. A transaction can be commercially necessary but poorly timed, within budget but incorrectly specified, or correctly specified but directed to the wrong location. Different approval responsibilities can address different parts of the decision.

A practical example

A maintenance team needs replacement equipment. In a fictional company policy, modest purchases require departmental approval, while higher-value requests require another management level.

The requester explains the need and expected consequence of delay. The department manager evaluates operational necessity. A further approver evaluates the larger financial commitment where the configured threshold applies.

DNA's multi-level rules can represent this structure for supported transactions. The threshold does not establish whether a purchase is good value; it establishes who must evaluate it. An approved request still needs an accurate specification and subsequent evidence of fulfilment.

Controls that remain meaningful

Approval becomes weak when the same person can prepare, authorise, and conceal a transaction without an independent check. This is why businesses often separate responsibilities for preparation, approval, custody, and reconciliation. The appropriate division depends on team size and risk, but ownership should remain clear.

A rule also depends on its supporting master data. A destination-zone approval requires an assigned responsible manager. A budget approval based on cost-centre responsibility requires that responsibility to be maintained. A technically active rule with no suitable accountable person can delay work instead of controlling it.

Exceptions need a reason. Urgency may justify expedited review, but it does not make missing specifications, duplicate commitments, or incorrect amounts disappear. The evidence should explain the decision and remain associated with the business record where supported.

What this means for daily work

A restricted action does not automatically indicate a system fault. It may reflect the user's role, an approval requirement, a processed document, or a downstream dependency. Understanding which control applies makes escalation useful: the business can identify the responsible owner and the decision required instead of requesting unrestricted access as a general remedy.

Good controls allow legitimate work to proceed with clear accountability. DNA provides the mechanisms; the organisation supplies the responsibilities and rules that give those mechanisms meaning.