Demos always start with features: reporting, approval, export. After go-live, sales sees all company prices, warehouse can change order addresses, finance and business share one approver. Incidents trace to "permissions not configured." In truth they were never designed. Features answer what is possible; authorization answers who is allowed. The latter comes first and is harder to change.
Authorization should be layered as view, approve, and edit—not menu checkboxes.
Two Failures of Retrofit Permissions
Too wide: shared roles, delegated authority chains, unlimited export. Data flies; compliance fails; internal negotiation gets polluted by price lists. Too narrow: lock the floor for safety and work returns to paper and WeChat—the system becomes a showroom. Both come from no role profile—only fear or convenience.
Approval chains copied from admin hierarchy are slow and hard to reject. Approvers do not understand; those who understand cannot approve.
Write Three Tables Before Features
- View: org scope and field masking—price, cost, ID numbers default to minimum visibility.
- Approve: amount, risk, and professional co-sign—do not pile all approvals on the top leader.
- Edit: changes to key master data and approved documents need audit trail and second confirmation—separate from "entry."
- Delegation is time-bound with expiry and audit of super roles.
The XYN digital intelligence system puts org permissions in one framework; scenario features can follow. Authorization before features gives the floor speed safely. Features before authorization turns speed into risk or decoration.
