AX1422

How plan file processes and security interact

When a user is an owner of a plan file for a step in a plan file process, their security permissions to the plan file are temporarily "elevated" as needed so that they can complete the process task. 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.

This approach means that the user's "baseline" security permissions should reflect the level of permissions that you want the user to have when they are not a process step owner. When the user is a process step owner, their permissions will be elevated as needed.

In order to become a step owner for a plan file, the user must have a plan file permission set in Security that includes the plan file (either configured on the user or inherited from a role). The plan file must fall within the user's plan file filter, or the user must be granted access to All Plan Files. Process management can elevate an existing permission to a plan file, but it cannot grant permission if the user does not have any existing permission to the plan file.

Additional rules apply, depending on whether the step ownership is assigned directly to a user name, or whether the ownership is determined by a role. See the following sections for more information.

NOTES:

Plan file processes can only elevate user permissions, they cannot decrease user permissions. If a user has Read/Write and Allow Save Data permission to a 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.
Axiom Financial Institutions Suite 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.
Administrators always have full access to plan files and file groups, regardless of their Security or Process Management settings.

Direct user assignments

When the owner assignment for a step is a user name instead of a role, that user is eligible to be the step owner as follows:

If the user has a permission set that grants at least Read Only access to the plan file, then the user can become the step owner and will have their permissions elevated as needed. In this case, Interacts with Process Management is not required to be enabled for the user to become the step owner.
If the user has a permission set that grants No Access to the plan file, and Interacts with Process Management is enabled for the permission set, then the user can become the step owner and will have their permissions elevated as needed. This allows a configuration where the user can only access the plan file when they are the step owner, but otherwise they have no access. If Interacts with Process Management is not enabled, then the user is not eligible to be the step owner.

In either case, the permission set can be configured directly on the user or inherited from a role.

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, the user is eligible to be the step owner of plan file 27000, even though their permission set grants No Access to the plan file. 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). If "interacts" was not enabled, then the user could not become the step owner.
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 the user has at least Read Only access to the plan file, the user is eligible to be a step owner of plan file 27000. 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). Interacts with Process Management is not required to be checked in this circumstance (though it can be, if you also want this permission set to be considered when the ownership assignment is a role—see the following section for more information).
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.

For both examples, if the user was assigned as the step owner of plan file 28000, the user would not be eligible to be the step owner, because that plan file is not part of the user's permission set. If a user is directly assigned as a step owner for a plan file, but the user does not have permission to the plan file, the plan file will stall in the process.

Role assignments

If the assigned step owner for a plan file is a role, then the way that users within the role become step owners depends on the Role Assignment Options defined for the step (see Assigning owners to plan file process steps). Additionally, the users' permission sets must have Interacts with Process Management enabled in order to be considered for step ownership.

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 Budget Process 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 for this user. This configuration 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. For more information on role inheritance for file group permissions, see Understanding role inheritance options for file group permissions.