AX1422
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. However, if you need the process to elevate the user's permissions, then Interacts with Process Management must be enabled.
IMPORTANT: If an individual user is directly assigned as a step owner, but the user's plan file permission does not have Interacts with Process Management enabled, it is a known issue that Axiom Software will elevate the user's permission to include Allow Save Data but not Read/Write. For this reason, it is recommended to enable Interacts with Process Management on plan file permission sets for any user that you plan to directly assign as a step owner, if that user does not already have full permissions to the plan file.
-
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 Software 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.
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.
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.
