Rules for Statuses
In defining our process, we set the logic for who should get to set each status. That means we need to create lock measures that correspond with that logic.
To create measures for those rules, it is important to first think about how to maintain the rules. Are they very static, so static infact, that they could be written directly within a measure? Or should they be ruled through one or more Data Input Tables?
In this case, we assume that we want to be able to change responsibilities and create a Data Input Table, starting with setting up an Other table in Storage Tables.
You could work with the SubProcessKeys that you have set up under Processes in order to separate different responsibilites. For example, your table could look like this:
Import your table and set relationships. You want the users to be stored on their Aimplan UserKey value as this is what will be used when comparing the actual user with credentials.

If you want to use the DimUser-table for Dynamic Dropdown-fields in your Data Input Table Visual, create a duplicate of that table without interactions and use these keys and names in your Fields in the visual.
The other fields we need are SubProcess, which we get from the table DimProcesses, and a new dimension, RoleID, which we need to create for this specific use. This can of course be added in different ways, in this case we simply add it with Enter data in Power BI.
Set up your relationships in Power BI.
Next, set up your Data Input Table, using dynamic dropdown fields. If you are unsure how to use the Data Input Table, read more about it here.
You now have all you need to set up your measures to lock different statuses. To begin with, you need to create a measure that compares the Current User Key with the list of assigned credentials from StatusRoles. This could look something like this:
This creates a boolean measure that generates the value null when the RoleID has a value smaller than 1, which is our lowest RoleID. This means that for users not included in the list, they get the value True (which would lock a value), whilst the users in our list get a blank.
If we look at the logic we want to set up, we can see that there are three different types of rules (lock-measures) we need to set up:
Process Key | Process Name | Action | Editable to |
|---|---|---|---|
0 | In Progress | Enables entering budget values. | If ProcessKey is smaller than 2, Manager and Head Controller can edit, otherwise only Head Controller can set status "In Progress" |
1 | Ready for Approval | Locks the Head of Department option to go back to "In Progress" | As long as Process Key is 0, this is open to anyone and ruled by the models RLS, else it is always locked |
2 | Approved by manager | Locks the Managers option to change back to "In Progress" This is the Managers approval to let Head Controller know they are done. If not approved, status is set back to "In Progress" | If ProcessKey is smaller than 2, Manager and Head Controller can edit, otherwise only Head Controller can set status "In Progress" |
3 | Locked | Marks the finalization of the Budget Process | Head Controller is the only one who can edit, always open for them. |

Assuming that a user higher in the hierarchy should always have the credentials of the users under them, we can create a RoleLock that tells us how many locked values a user has. The higher the value, the lower the credential is.
Using the RoleValue, together with a StatusValue defining the currently chosen status, you can now create separate lock measures. For example, for the status In Progress and Approved by manager where our condition is:
"If ProcessKey is smaller than 2, Manager and Head Controller can edit, othervise only Head Controller can set status"
The lock measure could be set up to look like this:
Once you have set up your lock measures, you implement them on each status that you want to lock. Read more about that here .