Planning Analytics Workspace 2.1.14 introduces two major enhancements to workflow functionality in Plans. These enhancements, Data Accountability and Workflow Processes, are designed to support TM1 Applications use cases in Workspace plans in addition to new use cases that require workflow capabilities. TM1 Applications is also commonly referred to as TM1 Contributor. If you are not familiar with the legacy TM1 Applications component of Planning Analytics you can find documentation here: https://www.ibm.com/docs/en/planning-analytics/2.0.0?topic=applications-getting-started-cognos
Data Accountability
The Data Accountability feature allows plan owners to assign members from an accountability dimension to Workspace groups. This process is very similar to the rights assignment feature from TM1 Applications. A contributor assignment is used to drive Planning Analytics Workspace users to slices of data in TM1 cubes where they may contribute or analyze data. An approver assigned is used to approve or reject submissions made by the contributor role. The workflow process starts with the contributor role taking ownership of a member in the accountability hierarchy, doing some work against that member and descendant members, and finally submitting the member. The approver role is then used to approve or reject any of the submitted members.
Documentation for the Data Accountability feature can be found here: https://www.ibm.com/docs/en/planning-analytics/2.1.0?topic=plan-specify-data-accountability-in
The existing notifications feature in Workspace plans has been improved to send email notifications when the state of the workflow is updated. For example, when a contributing user takes ownership of a member, other users in the group with access to that member receive a notification letting them know the member is now owned. When a member is submitted, users that have been assigned the approval role for the member receive a notification letting them know the member is ready for approval. The notifications are used to help plan participants know when their input is required.
The Data Accountability feature also applies the commentary system to member-based state changes. Comments entered when submitting, approving, and rejecting can be used to provide explanation for the state change. The comments that are attached to the member in the accountability dimension are visible to all roles that interact with that member.
The Data Accountability feature is intended to assign data to specific groups of users in Planning Analytics Workspace. The plan contribution experience provides the contributor and approver users with a subset of members from the accountability dimension. When a user selects a member from this set the books, views, and Websheets used in the task will be synchronized to that member. This mechanism makes it easy for the plan owner to direct users to the correct data. However, unlike TM1 Applications, the Data Accountability feature in Plans does not set TM1 object security, lock slices of data, or leverage Data Reservation. This is where the Workflow Processes feature applies.
Workflow Processes
Workflow Processes are used to automate changes in the TM1 model as the state of the workflow in Plans is updated. This feature acts as a bridge between Plans in Planning Analytics Workspace and the TM1 model.
Documentation for the Workflow Processes feature can be found here: https://www.ibm.com/docs/en/planning-analytics/2.1.0?topic=plans-automate-plan-actions-workflow-processes
A Data Accountability task in a plan can use the Workflow Processes feature to run a Turbo Integrator process when the task is activated or deactivated, and when the plan users take ownership, submit, approve, and reject members. Typically use cases when activating or deactivating the task include setting security in the TM1 model, creating security overlay cubes, and configuring the TM1 data reservation feature. When users take ownership, submit, approve, and reject, the Workflow Processes can be used to lock or unlock slices in the contribution cubes, or acquire or release data reservations. I have attached Turbo Integrator processes that can be used to set element security, lock and unlock slices, and acquire and release data reservation, similar to TM1 Applications.
Let us examine how Workflow Processes provide a connection between Workspace Plans and the TM1 model. When the first Data Accountability task is created in the plan, a cube is created to track the workflow state of members in the data accountability dimension. The name of this cube is generated based on the unique ID of the plan. In this example the plan ID is 82b7aac2-8418-495b-b749-ef37953192af and the state cube is }Plans_82b7aac2-8418-495b-b749-ef37953192af_state. The state cube contains a dimension with a list of the task IDs, one for each data accountability task in the plan, a dimension that mirrors the hierarchy used for approval, and a }Plans_State measures dimension.

For the activate and deactivate events, Workflow Processes configuration allows the plan and task IDs to string parameters of the Turbo Integrator process. This screenshot shows the Workflow Processes configuration for a task activation.

The Turbo Integrator process can use the plan and task ID to look up the state cube and read data including the PAW groups assigned as contributor and approver roles, state of each member in the accountability dimension, and current owner.
The take ownership, submit, approve, and reject events can be configured to pass the plan and task IDs in addition to the member in the accountability dimension the event happened on. This is an example of a Workflow Process configuration on the submit event.
This table provides a list of the Workflow Processes configuration with the sample provided processes. Note that most of these processes use the ExecuteProcess function to call other processes. The provided Turbo Integrator processes are samples that are used to demonstrate how the behaviors of TM1 Applications can be implemented in Workspace Plans. The provided process will require a minimal amount of modification as they are configured to use the plan_BudgetPlan cube in the Planning Sample model.
Event
|
Turbo Integrator process
|
Parameters (provided by plan)
|
Activate the task
|
Plans_ActivateTask
|
pPlan = PlanID
pTask = Task ID
|
Deactivate the task
|
Plan_DeactivateTask
|
pPlan = PlanID
pTask = Task ID
|
Reject the task
|
Plans_Reject
|
pPlan = PlanID
pTask = Task ID
pMember = Member
|
Submit the task
|
Plans_Submit
|
pPlan = PlanID
pTask = Task ID
pMember = Member
|
Take ownership
|
Plans_TakeOwnership
|
pPlan = PlanID
pTask = Task ID
pMember = Member
|
The provided Turbo Integrator processes do the following.
Plans_ActivateTask
Examines the state cube to find the Planning Analytics Workspace groups used for contributor and approver assignments. Groups are created in the TM1 database with the same name of these groups. Note that the TM1 groups are only created if they do not already exist. The group memberships in TM1 may need to be manually updated to match group memberships in Planning Analytics Workspace. A SecurityOverlayGlobal cube is created for each contribution cube. This list of contribution cubes must be manually set in the ActivateTask process. The data in the SecurityOverlayGlobal cubes is updated based on states for each member in the data accountability dimension. An element security cube is generated for the accountability dimension and security is assigned. Groups with the contributor assignment are provided WRITE access to assigned member and approver groups are provided with READ access. The Turbo Integrator process can be updated if approvers are intended to also have WRITE access to data. When used with TM1 11 the data reservation feature is also preconfigured for each contribution cube.
Plan_DeactivateTask
This process locks all slices in all contribution cubes based on the assumption that users should not be able to input data when the task is deactivated. Deactivating a task prevent users from accessing books and views with the task but does not prevent users from accessing the contribution cube outside of the plan. Users might still be able to examine the contribution cubes in Workspace books and PAfE reports.
Plans_Reject
Unlocks slices for the member from the accountability dimension that is rejected. Acquires data reservation for the last contributing owner of the slice. If rejecting a child member causes a parent member to be returned to the previous owner then the data reservation will also be reacquired on the parent member.
Plans_Submit
Locks slices for the member from the accountability dimension that is submitted. Releases data reservation on the slices.
Plans_TakeOwnership
Unlocks slices from the contribution cubes for the selected member in the accountability dimension. Acquires data reservation for the slices for the user taking ownership.
With the sample Workflow Processes configured in a Data Accountability task we can examine the output. Assume we have a Workspace group named ‘Planner 1’ assigned as a contributor to a consolidated member. This example uses the plan_chart_of_accounts dimension in the Planning Sample database for Data Accountability. The Revenue member has two child members, Sales and Other Revenue. A Workspace group named ‘Approver 1’ is assigned as the approver group.

Make sure the activate the Data Accountability task after configuring the Workflow Processes and setting the contributor and approver groups. If the task is already activated then deactivate and reactivate it to execute the Plans_ActivateTask process.
When a user in group ‘Planner 1’ opens the plan they are presented with the following. Note that the cells are grey, indicating read only.

Clicking the ‘Assign to me’ button takes ownership of the Revenue member. This action also execute the Plans_TakeOwnership process which acquires data reservation and unlocks the slice the user is looking at. The Workspace book refreshes and the white cell background indicates the cells will now accept input. The button at the bottom of the planning panel has changed to Submit, indicating the slice can now be submitted, presumably after the user inputs some changes to the data.

It is possible to take ownership and submit at any level. In the above example we took ownership of the consolidated member Revenue. Taking ownership at a consolidated level gives us ownership of all descendant members that are not already submitted or approved. It is also possible to take ownership at the consolidated level and submit members below the consolidation.
Additional Notes
1. Both the Data Accountability and Workflow Processes features are disabled by default in Workspace 2.1.14. These features can be enabled in Features and Configuration area of Planning Analytics Administration. It is possible to enable Workflow Processes without enabling Data Accountability as Workflow Processes can also be applied to regular tasks in a plan with a limited set of events.
2. Workflow Processes are run in the context of the user account performing the action. A plan contributor that is taking ownership of a member in a Data Accountability task must belong to a TM1 group with READ access to the process that is executed when they click the Assign to me button.
3. Workflow Processes that return an error will not inform the plan user about the error. The plan users are never informed the process is running at all. As a best practice, Workflow Processes should be designed to complete as quickly as possible. It is possible to configure notifications to the plan owners on failed Workflow Processes.
4. Workflow Processes run after the state cube is updated. This allows the Turbo Integrator process to read the updated state of Data Accountability members in the cube.
5. It is possible to release ownership of a member in the Data Accountability dimension by clicking the ‘x’ to the right of the current assignee. A ‘Release ownership’ event type for Workflow Processes is planned for an upcoming Planning Analytics Workspace update.
The sample Workflow Processes can be downloaded here