Build custom ‘process log’ within Anaplan

NoahJ

Author: Noah Jackson, Principal Data and Insights Architect at Anaplan.

In certain business process there are imports and actions that are not run on set schedules but are instead initiated as needed by end users. As a non-Admin user in an Anaplan model, it is sometimes very useful to be able to easily determine details regarding when those actions were last run, and by who. In this article I will present a method of building this functionality within Anaplan in a way that can be viewed by non-Admin end users. This will require having a separate ‘current time’ update process, which will be discussed shortly.

In the end you will have a module that lists your processes, when they were last run, and by who. It could look something like this:

Prerequisites and overview

Existing ‘Current Time’ update process

This log method assumes that you have an existing process that updates a ‘current time’ value within an Anaplan model. This is generally achieved via an integration script that uses an API to connect to Anaplan and update a ‘current time’ value at consistent time intervals – link to an example script discussion.

Your ‘current time’ value could also be in either the model in question, or in a hub model that all users running the processes have access to. However, as a warning, running a model-to-model import ‘locks’ the source model for the duration of the action. You should only source your ‘current time’ value from a separate model if the process you are logging already involves imports from that source model, so that you do not create new blocking actions on the source model.

Manual steps

This method involves multiple ‘hard coded’ steps that must be repeated for each process desired to be logged, so it is recommended to identify the few key processes that should be logged. If you want to log an individual action that is not already in a process, a process will need to be created for it.

Overview

If both of those prerequisites are feasible, then you will be able to create the following. I will give an overview of this “process run log” and the method to build it. The schema for this method includes one list and two modules that will be added to your model:

1. Step 1: Create the ‘Log Source’ module
   This module will serve as the import source for your log. It will be a staging for your ‘current time’ value, and be set with the ‘User’ dimension as the method of detecting who is running the action.
   1. Create a module with the native Anaplan ‘Users’ dimension of the module. In this module, create one line item called ‘Date and Time’, formatted as text, with applies to set as blank, creating a subsidiary view. Also, in the blueprint view, find the ‘Users List’ column and set the value for ‘Show All Users’ to “Off”.
      
   2. If the automated ‘current time’ value (discussed above) is stored within the same model, then link it to this line item via a formula. If it is in a separate model, create an import action that imports the ‘time’ value from wherever it is stored into this single, zero-dimensioned cell. This action will then need to be included as part of any process that is desired to be logged.
      
      The end product of this module is effectively two values – the single time cell, which will be updated by formula or import process, and the ‘current user’ value.
   3. Pivot the users into the ‘rows’ area, and the line items to the ‘column’ area. Save the view with the name of your first process. For example, if I have a process called ‘Update Employee Data’, then in my ‘Log Source’ module I should have a saved view that looks like this:
      
      Now we are going to create multiple identical saved views, named after each of our specified processes. This is because in Anaplan, a given source and target can only be saved as a single import action. Later we will want to effectively run the same import but with different mapping settings – this requires unique ‘import source’ values, which we achieve by saving our source with different names.
      Each saved view will look the same as all the others but have a different saved name. This will need to be repeated for each process to be logged – you will need one saved view for each.
      
2. Create the ‘Process List’ and ‘Process Run Log’ module to store the records.
   This module will be the one displayed to your end users, and it will be updated every time one of your specified processes are run.
   1. Create a ‘Processes List’ list. Manually add items corresponding to each process you desire to log.
      
   2. Then create a module called ‘Process Run Log’, with ‘Process List’ as the only dimension. In this module, create two line items: ‘User’ and ‘Date and Time’ (both formatted as Text).
      
3. Step 3: Create the actions to populate the ‘Process Run Log’
   To record the values into your ‘Process Run Log’, we will set up imports that will pull the current time and current user from the ‘Log Source’ module. One import will be created for each logged process, and those imports will be inserted into the processes themselves so that your log updates when the process is run.
   1. In your ‘Process Run Log’ module, select Data > Import, then select the saved view in your ‘Log Source’ module that corresponds to one of your processes:
      
   2. The ‘Processes List’ dimension should be set to ‘Fixed item in Processes List’, and the line items should be set to ‘Column Headers’.
      
      In the ‘Processes List’ tab, set the specified value to the desired list item that matches the saved view name chosen in step 3.1.
      
      Confirm that the line items are correctly mapped, and run your import to save it.
      
      This is why individual saved views were needed, so that we can save a multiple imports from the same ‘Log Source’ module to the ‘Process Log’ module each with a different ‘Fixed item’ import selection.
   3. You will have to repeat steps 3.1, corresponding to each process you want to log. It is then helpful to give the actions a more useful name then the default, for easier auditability of the actions table.
      
   4. Edit the processes you are logging. (If you want to log an individual action not already in a process, one will have to be made which will replace the button used by your end users). If you update your ‘Log Source’ time value via an import, that action will need to be added to each process that you desire to log. Following that action in the process, add the corresponding unique log import action.
      
      First, the log source will be updated with the current time, and then that time value and the current user will be pulled into the ‘Action Run Log’ module to be stored. (If your time value is connected to the log source via formula, then only the second action is needed).
   5. Repeat step 3.3 for each process you desire to be logged. After that is completed, then whenever your logged processes are run, the corresponding item in the ‘Action Run Log’ will be updated with the nearest time (as precise as the source value is) and the user that completed the action.
      

As an optional additional step, I personally wanted to A. Clean up the display of the time by rounding and removing extra decimal places, and B. display the information as non-editable to the end users. I added the following line items – these were specific to the format of date and time value in our ‘Data Hub’, and may need to be adjusted to fit your format:

Line item	Format	Formula
Time number	Number	MROUND(VALUE(MID('Date and Time', 12, 2)) + VALUE(MID('Date and Time', 15, 2)) / 60, 0.5)
Time text	Text	IF ISBLANK('Date and Time') THEN BLANK ELSE (IF Time number < 10 THEN "0" ELSE "") & TEXT(ROUND(Time number, 0, DOWN)) & IF MOD(Time number, 1) = 0 THEN ":00" ELSE ":30"
Time Run (PST, Nearest ½ hour)	Text	LEFT('Date and Time', 11) & Time text
User	Text	LOWER(Users)

Then only the final two columns were included in the view published to the page.

This completes the instructions on how to create a process log! I hope it is useful for you and your team.

kaitchura

Wow! This is so great! Thanks for sharing!

Tim_Mark

Thanks for sharing your approach. This is something that I've had in a backlog to do but never got around to! If you wanted to keep a record of all times a process is run would you create an child item belonging to a parent process to record the event? Auditing the previous values of the cell could suffice but is not as intuitive for users.

Tiffany.Rice

Very ingenious way to capture "history" without having to comb through the details of the model history. Appreciate you sharing!

Khadar

Wow! this is so remarkable! thanks for sharing!

NoahJ

You are welcome, I'm glad to hear it will help others!

@Tim_Mark yes, it would involve additional complexity but it definitely could be set up. You'd have to have some way of generating the code for the "log entry" item, but you could use the exact date and time or something (although if it was run twice since your central "time" value updated, it would overwrite). Otherwise you could reference the existing IDs and increment by one, or some other solution.

Best of luck!