Triggering TI Processes from TM1 Application Workflow
In TM1 10.2 a feature has been added to enable the change of workflow state of a node to trigger TI processes. A preset TI process can be triggered immediate before and immediate after the workflow action. This feature can be quite useful in a lot of ways, for example, if you have a separate BI report cube setup, when a node is submitted, TI process can be triggered to update the BI report cube without extra actions. And once all the nodes are locked, then you can be sure that BI reporting cube is ready for reporting, without running extra processes.
Here are few simple steps for Triggering a Process automatically:
- In Application Design mode, double-click on an application that you wish to update.
- In the Properties pane, scroll down to select Custom Processes, and click on the Ellipse … to bring up the Custom Processes Settings screen.
- Here you can specify which workflow actions can be enabled to trigger a TI process, either immediately before or immediately after the action, as well as the process need to be triggered.
There you go, a very useful feature that requires just a few simple steps.
Uses for Triggering a Process after an Application Workflow Status Change
This feature can potentially enhance and streamline the business planning processes. Some examples of how this feature can be used:
- Updating BI Reporting Cube: To ensure the BI reporting contains the latest planning data, TI process can be triggered immediately after a node is committed or submit. A process is triggered to update a separate reporting cube (it would not matter if it is on the same or different server instance) from the planning cubes. This would not require separate action to update BI reporting cube (or improve efficiency in case your reporting cube is linked by rules).
- Import latest actuals from ERP: To ensure the user is seeing the latest and greatest actuals from your ERP, a TI process can be kicked off to import actual financial data from EPR just before user takes ownership.
- Notify other users when a node is committed: When there are multiple contributors to an application node, can utilise a TI process to notify all relevant users that data is updated, and peer review may be required.
- Trigger report distribution/printing: When a top consolidation node is locked/submitted against a business unit, it triggers report distribution to all managers for that particular business unit. If all managers have access to the reporting portal online, this TI process can act as a notification mechanism.
- Sending reviewer or contributor an email on submit or reject of a node: triggers a process to notify all parties involved.
- Process to lock/unlock a node: In some cases, the business may want to prevent contributors from updating a node when it has been taken offline. A process can be triggered to lock access on the server to that specific node immediately after it has been taken offline, and a process to unlock it just before it is brought back online again.
The list can go on and on, it really depends on your business and application, and how this feature may enhance your planning process.