Register

Copy Branch Workaround for the User Experience

The ‘Copy Branch’ action hasn’t currently made its way onto the UX, so I was recently challenged by @Paul to create a workaround. This is my relatively simple solution, which could be amended for “Assign” by deleting the items in the ‘copy from’ list once copied.

It should be noted that it is not a best practice for users to run actions as this can cause concurrency issues, so please take this into consideration when designing your process.

In this model, I am copying a department and all the employees belonging to it, to a newly created department. As you increase the size of the hierarchy then the complexity would obviously increase, but the logic should still hold.

The video below demonstrates it working:

NB:- References to a staging module in the commentary can be ignored, as the model was simplified and the actions of the staging module were moved into EMP01

To further explain the logic, I am creating a new department (Commercial in this case), which also creates a code for the new department (Comm) and ticks the branch to copy in the module.

Screenshot 2021-02-09 at 16.23.41.png

Screenshot 2021-02-09 at 16.24.26.png

This allows me to filter this view to act as a source for import into my L2 department list.

Screenshot 2021-02-09 at 16.25.07.png

It also feeds into the SYS01 and EMP01 modules to allow me to highlight the employees (branch items) that I need to copy.

Screenshot 2021-02-09 at 16.25.48.png

This, in turn, ticks the copy included line item below. The view can then be filtered to just the ticked items.

Screenshot 2021-02-09 at 16.26.41.png

Screenshot 2021-02-09 at 16.27.59.png

This filtered view can then be used as an import for the relevant items into the L3 Employee List and the details—then into the EMP01 module to hold all of the required details (in this case only name and salary). I am also generating a “New” code at this point, which needs to be something distinct, especially if the same branch will be copied frequently. In this case, I have added the department #No to the name eg #13Shaila Engle. For best practice see Planual Rule 2.02-05.

Screenshot 2021-02-09 at 16.28.44.png

Once the imports are complete then the editable fields are highlighted in blue. This would be relevant in certain environments, but for others, we would be looking to list format against a flat employee module. Planual Rule 1.05-5 Display Name 

The new department field etc in DEP01 are filled with blanks to reset to a clean module (Action: EMP5).

Action details

This would be a single process button in an operational model, but I have broken it down into three processes here to demonstrate what is happening in the model. The processes create the department and filter the employees to be copied, copy the employees and then finally clear out the staging module and other temporary requirements.

Screenshot 2021-02-09 at 16.29.47.png

0 Kudos
The content in this article has not been evaluated for all Anaplan implementations and may not be recommended for your specific situation.
Please consult your internal administrators prior to applying any of the ideas or steps in this article.
Comments

Brilliant, Paul!

Simple, yet powerful!

Thanks Paul.  We have been asking for a solution for this for a while for a number of our customers this is stopping them from moving to the UX.  It's great to have a workaround but do you know what the plan is for building the full functionality into the UX ?

About the Author
Labels (2)