User Guide: Moving Entities Across Business Modules

1. Introduction

2. End User Guide

3. Notes

This feature allows the user to move entities from one business module to another. This is useful in various cases.

An example could be if a solution has a Projects business module which contains all active projects, and another Projects module used to store all archived projects. This feature makes it possible to move a finished project from the active Projects module to the Archived Projects module for storage. This makes the solution more scalable and help respect limitations on entity counts. WorkPoint Business Modules performs best if the entity count is below 5000 because of Microsoft SharePoint software boundaries and limitations. This is especially true if unique permissions are assigned to many entities. So, in case a solution approaches this count, but many of the entities are completed, it is now possible to move these to a separate storage module using this feature.

Another example could be moving items from a pipeline module to a project module. When a lead in a pipeline module becomes a project, it can now be moved to a project module. So instead of combining many modules/stages into one module it is now possible to divide the module into multiple modules and move the entity through the modules during the entity lifecycle.

Another great aspect about this feature is that it is possible to set up security settings tailored for both the active projects and the archived projects, should these differ for the solutions users.

This feature can be used through the WorkPoint 365 WebAPI. For more information about the WorkPoint 365 WebAPI, visit this website: https://support.workpoint.dk/hc/en-us/articles/206969638-WorkPoint-365-Web-API. The Move Action is described technically in detail in this link: https://wp365webapi.azurewebsites.net/Help/Api/POST-api-Entity-Move.

It can also be used in combination with the Action Management feature. E.g. when a project changes stage to “Archived”, it would automatically trigger an action to move the entity to the archive module

It is important to note that the site for the entity does not get copied. The site for the entity is still the same after moving the entity.

If the move entity action is set up with a stage change trigger, the user moves the entity by changing the related stage, however this is done. This can be done e.g. through a wizard (1), assuming such a wizard is set up, or by clicking the next stage in the stage overview of the project ((2) and (3)).

This will in effect trigger the move action, and the project will be moved to the Archive module.

The action could also be executed by clicking a button on the My Tools panel:

Clicking this button will in effect execute the move entity action, and the entity will be moved to the Archive module as shown in the image below:

Note that at first the TestProject3 is located on the Projects module list. After clicking the “Move Project to Archive, the project is now located in the ProjectsArchive module list.

It is important to understand that when moving an entity from one business module, the site does not change. Only the entity gets moved. This is illustrated in the image below:

As shown in the image, the first item from the Projects module is moved to the Projects Archive module, but the site stays where it is and the link from the moved entity to the site also persists.

It is also very important to note that fields are mapped solely by looking at field names and field types. If internal field names and field types match between the two business modules, the values will be moved over. If not, the values will be ignored and not moved over. It is therefore important that the relevant fields match between the two modules in case the information is important to keep through the move action