All actions taken upon an agreement or provided to the post-award management system must be tied to a role.
Many users may be assigned to a role and batch actions from external systems (within and outside of FACET-Acq) must also be assigned to a role. The key point here is that user actions and system actions are identical in effect and should be indistinguishable from each other outside of security activity logging.
Roles for the system should be based on major system functions and must implement the least-privilege principle.
A note on separation of duties
It is key to separate business processes from the actual separation of duties requirements for roles.
While a business process may dictate additional oversight (approvals from a new role) for entitlements of a specified threshold, this is not core functionality to the system and these requirements can change drastically over time. Therefore they should be handled as additional packages or external services to maintain core usability and maintainability while still providing enforcement of business need. These sorts of requirements are best run through segregated code maintained outside of the application itself.
Conversely, a role capable of adding new vendors to the approved seller list or of changing payment account information related to a seller must not be concurrently held with the ability to entitle invoices for vendors as this is a true separation of duties need for the system. These are based in system and accounting best practices, for an example, see this matrix from Vanderbilt University's School of Finance
All actions taken upon an agreement or provided to the post-award management system must be tied to a role.
Many users may be assigned to a role and batch actions from external systems (within and outside of FACET-Acq) must also be assigned to a role. The key point here is that user actions and system actions are identical in effect and should be indistinguishable from each other outside of security activity logging.
Roles for the system should be based on major system functions and must implement the least-privilege principle.
A note on separation of duties
It is key to separate business processes from the actual separation of duties requirements for roles.
While a business process may dictate additional oversight (approvals from a new role) for entitlements of a specified threshold, this is not core functionality to the system and these requirements can change drastically over time. Therefore they should be handled as additional packages or external services to maintain core usability and maintainability while still providing enforcement of business need. These sorts of requirements are best run through segregated code maintained outside of the application itself.
Conversely, a role capable of adding new vendors to the approved seller list or of changing payment account information related to a seller must not be concurrently held with the ability to entitle invoices for vendors as this is a true separation of duties need for the system. These are based in system and accounting best practices, for an example, see this matrix from Vanderbilt University's School of Finance