AX1422

How plan file processes and security interact

In order to control access to plan files using a plan file process, plan file security permissions for users and roles should be set as follows:

  • For every user whom you want to participate in the process, enable the Interacts with Process Management option for the plan file permission in security.

  • The plan file access level for the user can be set to any level, including No Access.

  • The plan file permission must either have a defined plan file filter, or grant access to all plan files. This determines the list of plan files that the user is eligible to own in the process.

This "baseline" security permission determines the user's access level to plan files when no plan file process is active for the file group. However, if a plan file process is active for the file group, then the process will "elevate" the user's permissions as needed when the user is an active step owner. Otherwise, the user's baseline security permissions apply.

This permission elevation works as follows, depending on the step type:

  • Edit Plan File steps: If the user is the current owner of a plan file for an edit step, that user's rights to the plan file will be temporarily elevated to the equivalent of Read/Write and Allow Save Data while the step is active. Once the plan file is submitted to the next step, the user's rights to the plan file will revert to their baseline security permissions.

  • Approval steps: If the user is the current owner of a plan file for an approval step, that user's rights to the plan file will be read only, unless the approval step has been configured to allow reviewers to edit the plan file. If reviewers can edit the file, then the user's rights will be temporarily elevated to the equivalent of Read/Write and Allow Save Data while the step is active. Once the plan file is approved or rejected, the user's rights to the plan file will revert to their baseline security permissions.

Keep in mind the following regarding the interaction between security and plan file processes:

  • Plan file processes do not grant permissions to plan files, they only elevate existing permissions. If a user is assigned as the step owner for a plan file, but the user does not have a permission set that includes that plan file, then the user cannot be the step owner and the plan file will stall in the process.

  • Plan file processes can only elevate user permissions, they cannot decrease user permissions. If a user has read/write permission to a particular plan file, then that level of permission is always available to the user, regardless of whether a plan file process is active and whether the user is the current step owner.

  • When individual users are assigned as step owners, the user is not required to have the Interacts with Process Management permission in order to be the step owner. If the user already has the appropriate level of permissions in security to access the plan file and complete their process tasks, then Interacts with Process Management has no effect. However, if you need the process to elevate the user's permissions, then Interacts with Process Management must be enabled.

  • When roles are assigned as step owners, then users in the role must have the Interacts with Process Management permission in order to be evaluated as potential step owners. See Role assignments, security, and step ownership for more information.

Administrators always have full access to plan files and file groups, regardless of their Security or Process Management settings.

NOTE: Currently, Axiom Budgeting & Performance Reporting does not automatically regenerate active process tasks in response to security changes. This may result in situations where a current plan file owner cannot access or save their assigned plan file, if their security permissions have changed since the task became active. The administrator or process owner must manually regenerate tasks as needed in this situation.

Examples of a plan file process interacting with security permissions

The following examples are intended to help illustrate how plan file processes work in conjunction with security permissions to control access to plan files.

Example 1: No Access

  • This user's configured access is No Access to plan file 27000, which means that under normal circumstances the user cannot see or open this plan file.

  • Because Interacts with Process Management is checked, when the user is the owner of the active step in a plan file process, their access will be elevated as appropriate for the step (for example Read/Write and Allow Save Data for an Edit Plan File step).

  • While the step is active, the user will be able to access and edit the file, and save data from the file (if applicable). Once the user completes the process task and the plan file moves on to the next step, the user will no longer be the step owner and they will revert to having no access.

  • The user must have a permission set with Interacts with Process Management enabled in order for the process to elevate the permissions. If Interacts with Process Management was not checked in this example, then the user could not be the step owner because the user doesn't have any access to the plan file.

Example 2: Read-Only Access

  • This user's configured access is Read Only to plan file 27000, which means that under normal circumstances the user can see the plan file and open it as read-only.

  • Because Interacts with Process Management is checked, when the user is the owner of the active step in a plan file process, their access will be elevated as appropriate for the step (for example Read/Write and Allow Save Data for an Edit Plan File step).

  • While the step is active, the user will be able to edit the file, and save data from the file (if applicable). Once the user completes the process task and the plan file moves on to the next step, the user will no longer be the step owner and they will revert to read-only access.

  • The user must have a permission set with Interacts with Process Management enabled in order for the process to elevate the permissions. If Interacts with Process Management was not checked in this example, the user would still be assigned as the step owner, and the user could see and open the file as normal, but their permissions would not be elevated to allow saving data. If the user was only an Approval step owner, that might be acceptable, but if the user is an Edit Plan File step owner, then the user would require their permissions to be elevated.

If the user has Read/Write and Allow Save Data permissions, then Interacts with Process Management is not required to be checked if the user is directly assigned as the step owner, because the user already has the full level of permissions that could be granted by the process. However, if the step ownership assignment is through a role rather than for the user directly, then Interacts with Process Management must be checked if you want the user to be a step owner. The permission set will not be evaluated for potential step ownership through the role if the setting is not checked.

In all cases, the user must have a permission set that includes permission to the plan file. If Interacts with Process Management is checked but none of the user's permission sets include the plan file that the user is assigned to in the plan file process, then the user cannot be the step owner and the plan file will stall in the process.

Role assignments, security, and step ownership

If the assigned step owner for a plan file is a role, then the way the step owners are determined depends on the Role Assignment Options defined for the step. For more information, see Assigning owners to plan file process steps.

All permissions

If the step is configured to use All permissions, then the specific step owners are determined as follows:

  • All users assigned to the role are eligible to be step owners, regardless of the specific role permissions for the plan file and regardless of the role inheritance settings defined for the user. The role assignment simply defines the list of potential owners.

  • If a user within the role has any permission set for the file group that includes the plan file AND has Interacts with Process Management enabled, then that user is assigned as a step owner. It does not matter whether that permission set is associated with the assigned role. The permission set can be defined at the user level, or defined for any role that the user belongs to, or result from some combination of user and role permissions (when using Combine inheritance).

For example, imagine that a user has a configured permission set that grants Read-Only access to the plan file, and the user also belongs to a role named Budget Process. The Budget Process role does not grant access to the plan file. If Budget Process is assigned as the step owner, and the user's permission set has Interacts with Process Management enabled, then the user is a step owner. If Interacts with Process Management is not enabled for the permission set, then the user will not be a step owner, even though they have permission to the plan file and they belong to the role.

Now imagine a user who belongs to two roles, Budget Process and Finance. The Budget Process role does not grant the user any particular plan file permissions, but the Finance role includes the plan file in its filter and also has Interacts with Process Management enabled. If Budget Process is assigned as the step owner, then the user will be a step owner due to the permission they inherit from the Finance role. The user's membership in Budget Process makes the user eligible to be a step owner, and then at that point all permission sets for the user are evaluated to determine whether they will be a step owner.

Lastly, imagine that the Budget Process role itself grants access to the plan file and has Interacts with Process Management enabled. If Budget Process is assigned as the step owner, then all users who belong to the role will be step owners, because they are all inheriting the permission from the role. The only exception is any user with their role inheritance set to None. However, even in that case the user could be a step owner if they have another permission set with rights to the file and Interacts with Process Management enabled.

Role permissions only

If the step is configured to use Only permissions associated with the assigned role, then all users assigned to the role are eligible to be step owners, just like when using the All permissions option. However now the permission sets that are considered to determine step ownership are limited to permissions on the role itself, or to any individual user permission sets that are explicitly combined with the role.

If the role itself grants access to a plan file and has Interacts with Process Management enabled, then all users in the role are step owners of that plan file (except for any users in the role who are configured to not inherit the role's plan file permissions). This setup has limited usefulness, but might be appropriate in certain situations. For example, you might have a role with a small number of Finance approvers, and each plan file needs to be approved by someone in this role.

This option is most useful when users in the role have individual permission sets that are explicitly combined with the role. When using this approach, you can use the role to define the pool of eligible users, but use the filters defined on each individual user to determine step ownership for each plan file. All other inherited and configured permission sets for the user are ignored, so this option is especially useful when users may belong to many different roles but you want to limit the step ownership to permissions associated with a specific role.

For example, imagine that a user belongs to the Budget Process role, and this role does not grant any permissions to the plan file. If Budget Process is assigned as the step owner, the user will be the step owner for Dept 25000 if they have an individual permission set that is combined with the role as follows:

Because Role Inheritance is set to Combine with the role Budget Process, the user permissions and the role permissions are merged together and treated as a single permission set. This makes the user eligible to be a step owner for Dept 25000 using the Budget Process ownership assignment. If instead the Role Inheritance was set to None or Independent (or if a different role was specified to combine with), then this permission set would not be considered for step ownership. This permission set would also not be considered for step ownership if Interacts with Process Management was disabled, even if it still combined with the Budget Process role.

The user could belong to several other roles, but any permissions inherited from those other roles are ignored in this case. Similarly, the user could have other individual permission sets, and they will also be ignored unless they are set to combine with the Budget Process role.

Keep in mind the following:

  • If the user's permission set is configured to combine with all roles instead of with the specific role, that permission set does not count as associated with the role and will not be considered for step ownership. Only user permission sets that are explicitly combined with the named role are considered for step ownership.

  • If a user has only one defined permission set and that permission set is configured to combine with a specific role, the user will not inherit any additional plan file permissions from other roles. If you want the user to inherit permissions from other roles independently, you can create a "dummy" permission set for the user that has no permissions, but is configured with Independent inheritance.

NOTE: When a user's individual permission set and a role are configured to combine, the user is granted the most permissive set of rights as defined for either the user or the role.