1 Users cannot grant themselves new permissions as a result of updating a resource. For example, users cannot change the value of an attribute to give themselves Update rights if they did not have those rights already.

2 Users cannot give away permissions that they had as a result of updating a resource. For example, if users have Read + Update rights, they cannot change the value of an attribute so that they can no longer Read or Update it.

3 Fail fast when possible: For example, in order to BOM load, users need to be able either to Create and Read and/or Update the parent roll-up and potentially any functional group roll-ups. aPriori checks these conditions up front and fails immediately if it finds a problem, before starting the BOM load operation.

4 Keep going and notify: Once past the initial "fail fast" checks, for operations that involve manipulation of multiple scenarios, aPriori skips over scenarios that fail due to Access Control but logs the issue and notifies the user. For example, after the initial check for roll-ups, the BOM loader loads everything it can and notes any access control failures.

5 Abort the entire operation: If any part of an Update operation fails due to Access Control, the entire operation is aborted and aPriori attempts to clean up (delete) any scenarios created up to that point. For example, Scenario > Save As > Scenario & Children could fail an Access Control check after already processing some number of scenarios. In this case, aPriori stops the save and cleans up any scenarios that were created. (Spreadsheet reports work in the same manner, except that there is no need to clean up.)

6 Check before destroy: aPriori checks Access Control permissions before deleting data. For example, using File > Import to import scenarios from an ".ap" file will delete any existing scenarios that conflict with the ones being imported. Before performing the delete, aPriori verifies that the importing user has the necessary permissions for the entire import to succeed.