Security, Approvals, and Extensibility for Inventory
Security, Approvals, and Extensibility for Inventory
This domain tests who can do what in Inventory, how approvals are configured, and how to extend without breaking upgrades. The exam focuses on roles, privileges, data security, BPM approvals, and sandbox extensibility.
Core rules
- Job roles inherit duty roles, which contain privileges. Inventory transaction privileges control actions such as receive, issue, transfer, and count.
- Data security policies restrict access by inventory organization, business unit, or other dimensions. A user with the right privilege still needs data access to the organization.
- Approvals use BPM workflows. Transaction approvals can be conditional, for example by amount, item, or organization. Movement requests and adjustments are common approval candidates.
- Extensibility uses sandbox, Application Composer, Groovy, and REST. Extensions should be published from a sandbox and tested; direct customization of core objects is not supported.
Worked example
A warehouse clerk in WH1 must not see WH2. Assign a job role that includes inventory receiving and issue privileges, then add a data security policy limiting access to WH1. If adjustments above 100 units require approval, configure a BPM rule on the adjustment transaction. The reasoning: privilege grants the action; data security grants the organization; the approval rule adds control. Without the data security policy, the clerk could transact in WH2 if the role has global data access.
Traps
- Granting a broad job role and assuming organization access is automatically restricted.
- Confusing duty roles with privileges; duty roles aggregate privileges but do not replace data security.
- Building an approval rule that never fires because the condition field is not available in the transaction context.
- Publishing a sandbox without testing or without understanding that some changes require a new sandbox.