1 You cannot grant yourself new permissions as a result of updating an entity. For example, you cannot change the value of an attribute to give yourself Update rights if you did not have those rights already.

3 You cannot give away permissions you had as a result of updating an entity. For example, if you had Read + Update rights, you cannot change the value of an attribute so that you cannot Read or Update it anymore.

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

5 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.

1 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 rollups, the BOM loader loads everything it can and notes any access control failures.

2 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.)