Goal Plan States provide the ability to have more than one set of permissions. The difference between states can be subtle or drastic depending on the customer’s needs.
Watch the video to learn more about Goal Plan States.
Real World Scenario for Goal Plan States
A customer sees the Goal Management module and feels that they need to have a signature after goals are set. Additionally, the customer may request to ‘lock down’ or ‘approve’ the goals after they have been acknowledged.
The consultant explains that there are no signatures or workflows used in Goal Management and that this functionality only exists in Performance Management.
- Goal Plan States can be configured to record approval/acknowledgement and potentially remove permissions that replicate the ‘lock down’ of goals. This feature allows components of the Goal to be locked once an authorized user locks the plan (E, EM, and so on.)
- The permission to change states is configured by relationship role (not RBP). The different states do not have to vary drastically, permissions can be anywhere from identical, to opposite, or anything in between.
When the goal plan is unlocked (not approved), the E role should be able to create, delete, move, cascade-align, cascade-push, and share goals. The E should also have write permissions to all fields when adding/editing a goal. The figure Unlocked Goal Plan illustrates the unlocked (unapproved) goal plan.
When the goal plan is locked (approved), the E should not be able to create, delete, move, or cascade goals. The E should not be able to edit any fields anymore; the goal fields should be read only to the employee. The figure Locked Goal Plan illustrates the locked (approved) goal plan.
Goal Plan States Configuration
goal-plan-states element is used to configure the goal plan states. It is placed in the XML after the last
field-definition element and before the
goal-plan-states element contains the sub-element
goal-plan-state which must be added twice, the first one with
id=unlockedand the second one with the
goal-plan-stateselement groups all the action and all the field permissions into an unlocked and locked state. This allows you to control the action and field permissions prior to a goal plan being approved, and after the plan is approved. You cannot have permissions outside of the
Simply copy-paste the existing permissions within the goal plan state code and close off the goal plan state code with end tags. Look at the opening tags of the code to see what the code should be closed with.
Be sure to practice version control!
Obj-Plan-States Code Explained
Select the buttons to see the element code and learn more.
The goal plan states code should be placed after the last
</field-definition>, and before the
When using Goal Plan States, you may not want to include some action permissions for a more restrictive state. This is fine, but when uploading the Goal Plan XML template in Provisioning, you may notice red warning messages if certain action permissions are not present. You can still proceed and ignore the warning messages, if that is the configuration requirement.