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.
This allows me to filter this view to act as a source for import into my L2 department list.
It also feeds into the SYS01 and EMP01 modules to allow me to highlight the employees (branch items) that I need to copy.
This, in turn, ticks the copy included line item below. The view can then be filtered to just the ticked items.
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.
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).
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.