Action Management

1. Introduction

2. Requirements

3. Configuration

   3.1. Example: Action with Manual Trigger

   3.2. Example: Action with Stage Change Trigger

   3.3. Types of Actions

       3.3.1. Item Creation Action

       3.3.2. Lock Entity Action

       3.3.3. Unlock Entity Action

       3.3.4. Create Site Action

       3.3.5. Send Mail Action

       3.3.6. Set Default View Action

       3.3.7. Move Entity Action

       3.3.8. Connect to Office 365 Group Action

       3.3.9. Change Welcome Page Action

       3.3.10. Notify WorkPoint365 Web Hooks Action

   3.4. Types of Triggers

       3.4.1. Entity Creation Trigger

       3.4.2. Stage Change Trigger

       3.4.3. Manual Trigger

       3.4.4. Entity Updated Trigger

4. End User Guide

5. Notes

Action management makes it possible to create tasks jobs for the system to do (Actions) and define when the system should execute those tasks jobs (Action Triggers). You can, for example, make the system send an email to certain recipients under certain circumstances, or generate a document whenever a stage is changing.

Generally, you first want to create the Actions that you want the system to perform. Then you would create the Triggers that should make the action happen.

Usually actions are set up to be either executed manually by clicking a button in the My Tools-panel of the solution, or automatically once a certain event triggers, such as a stage change.

This system minimizes the manual configuration and creation of many different aspects of WorkPoint solutions, and thus makes it possible for the users to focus more on their actual work instead of having to spend time configuring the solution.

A use case for the Action Management feature could be when a company has a Projects business module which holds all the projects that the company is working on and has worked on. The company has a lot of finished projects that are no longer active. To avoid performance impair of their solution due to exceding the recommendation of maximum 5000 entities per site, the company wants to move all inactive projects to an Archive module. The company wishes for their solution to automatically move projects to the Archive module when projects enter the “Archived” stage.

They therefore use the Action Management system to set up a Move Entity-action together with a Stage Change-trigger. They set it up to move Projects to a ProjectsArchive module as they transition to an Archive stage. This now helps them not cluttering the Projects module list further.

Using Action Management requires purchasing the Action Management feature. Contact WorkPoint Sales at sales@workpoint.dk for more information about how to acquire the Action Management feature.

1. In this example, we are in the Action Management interface of a Projects business module.
2. Two actions, “Create Office 365 Group” and “Move project to Archive” are set up.
3. Two action triggers, “Connect to Office 365 Group” and “Move Project to Archive” are set up.

Looking at the Create Office 365 Group action, it is set up in the following way:

1. A title is given.
2. The Action is set active.
3. A field is selected to use as the Office 365 Group name.
4. A field is selected to use as the DisplayName .
5. A field is selected to use as the Description of the Office 365 Group.
6. The group is set to Private (a value of “no” in the Public field is equal to a state of Private).

Looking at the associated trigger, the “Connect to Office 365 Group” trigger, it is set up as follows:

1. The type of this trigger is “Manual Trigger”. This means that to perform the associated action, some manual action must be taken.
2. A title for the action trigger is given.
3. The permission level of the trigger is set.
4. The action previously described, the “Create Office 365 Group” action is chosen as the action of this trigger.

In this example, a button is then set up in the My Tools menu. This button will create an Office 365 Group and a Microsoft Teams site for the project entity that we are currently on:

In this section we will look at another example of a way to set up actions and triggers.

Consider the following action of type “Move Entity”:

1. A title is set.
2. The action is set to Active.
3. A Target Business module is set. Note that for any target business module to be available, another business module with a matching Module Group name as the one for which we are currently configuring must be present in the solution. In this case, our Projects module and our ProjectsArchive module share the same Module Group name, and the ProjectsArchive is therefore selectable.
4. A Target Stage is chosen. If a stage structure similar to that of our Projects module is present on the target module, the target stage will persist through the move, unless otherwise specified here.

This action is paired with an action trigger of type “Stage Change Trigger”, which is set up as follows:

1. The type of trigger is “Stage Change Trigger”.
2. A title is set for the trigger.
3. The default stage model for the is selected, which affects which choices we have in pt. 4.
4. The trigger is set to execute its action once a project changes stage from “Closed” to “Archived”.
5. The action previously mentioned (the “Move project to Archive” action) is selected as the action to be executed.

Once set up, this combination will execute on a project once its stage transitions from Closed to Archived. When this happens, the project will automatically be moved from the current Projects business module to the ProjectsArchive business module.

This action will create documents/items on the current site. Usually, the user will want the created document to be based on some template from the WorkPoint Template Library. The user can in this case add mappings to be able to pull information from fields on the solution to the document.

This action is useful e.g. when you want to create document which holds data from the WorkPoint solution. One example of this is when creating a coversheet for a transmittal. In this case, a template can be set up with field mappings and stored in the template library of WorkPoint. A link to the coversheet template in the template library can then be created on the business module master site. Using the Item Creation Action with a "Based on Field Rule" setup (explained below) you can then create a coversheet with automatically filled in data from the business module, based on e.g. a stage change or a manual button press. The setup for the Item Creation Action for this purpose would be something like the following:

Below is shown an example of the interface for creating the Item Creation Action when first opened:

Based on what is chosen as Item Creation Action Type, different information must be filled out in the rest of the interface. Generally, a title must be given, as well as an active state.

• All Items Rules.

This type will copy all documents/items from the business modules master site in the library specified in the “List” field.

• Advanced Rules.

With this type the administrator can choose a list and type in a CAML query in order to identify which items should be created. An example would be:

This would look through the list on the master site, and all items it found with a wpStatus that is not equal to “Completed” will be created in the entity list.

• Based on Field Rule.

With this type, the administrator can choose a list to look in for a field with a specific name, and a specific value. The system looks through the master site list specified, and all items returned will be created on the entity list.

One thing that can be configured for all of these types are mappings. Mapping is where a value is taken from an entity field and is 'copied' to a corresponding field on an Entity list field. You can choose either a People field or a DateTime field.

When you are using DateTime fields you can also choose a number field on the Master Site list, where the value of the field will add the amount as days to the Mapping.

This action will lock the entity. The entity can either be locked by record management or removal of add/edit/delete permissions on the entity. All documents on the entity site will be iterated and declared as records. Further, all add/edit/delete permissions will be removed from the web, lists and items related to the entity. This leaving only read-only access to the elements.

A case where this action is useful is when a project goes into the Closed phase, and the entity no longer should be edited. It is important to note that if there is a chance that the entity needs to be re-opened, locking the entity should be done using record management, as that setting can be rolled back, effectively reopening the documents for editing. If locking the documents and items by removing the permissions to do add/edit and delete actions, these cannot be directly restored later by the Unlock action but are instead re-inherited from the current security settings by the entity.

Below is shown the interface for creating a Lock Entity Action:

The action requires a title, an active state, and an Entity lock type (record or permissions).

This action will unlock the entity and restore permissions based on the security settings for the entity business module.

A useful case for this action is if a previously closed project needs to be re-opened. Note that if the entity was locked using record management, the entity will simply be unlocked and available for editing. If locking was done by removing add/edit/delete permissions, the current permissions will be inherited down onto the entity. This means that if security settings have changed after the permissions were removed, the new settings will be inherited by the entity.

Below is shown the interface for creating an Unlock Entity Action:

The action required only a title and an active state.

This action will create a site for the entity. This gives you the option to postpone site creation. When using this action, automatic site creation should be disabled on the business module.

This action is useful if a team only wants to create a site for its project when then project enters a specific stage. Say the team does not need to store any documents or record tasks or the like before the planning phase of the project. With this action they can combine it with a Stage Change Trigger to postpone the creation of the project site until they enter the Planning phase.

Below is shown the interface for creating a Create Site Action:

This action requires only a title and an active state.

This action will send an email based on a word email template from the template library. The email body and subject can be merged with information from the entity. You can also include documents from the document libraries on the entity site. These will be added as attachments in the email. You can configure the 'To', 'Cc' and 'Bcc' addresses of the email here, but you can also get the addresses dynamically from a user field on the entity when the action is triggered. It's also possible to combine the two options.

A case where this action might be useful is when a project goes from the Planning phase to the Active phase. In this case, an email could be sent to all people who should know that this project has now started development.

Below is shown the interface for creating a Send Mail Action:

This action requires a title, an active state, a subject, and a body. IT also requires an email address to send the email to. This email can either be typed in directly in the interface or pulled from a field on the solution. This also goes for the “Cc”- and “Bcc” fields. Furthermore, the interface the usage of an email template pulled from the template library in WorkPoint. Finally, attachment(s) can be added to the email by providing a document library for the attachment(s), as well as a CAML query to locate the file(s).

This action will set the default view of the specified list. This makes it possible to have different default views for different stages of a project, for example.

A case where this action is useful is if a list of a solution has a lot of different views that are meant to be used at different stages of a project. Instead of having a basic default view and having to change view every time the project is visited, the default view of the list can be defined by the current stage of the project. This minimizes the work the user must do to view the current relevant information.

Below is shown the interface for creating a Set Default View Action:

The action requires a title, an active state, a list or library for which to set the default view, and a view to set as the default view.

This action will move an entity from one business module to another. The source and target business module must have matching business module group names to be selectable. Business module group names can be set in the individual business module settings, as shown in the following image:

A stage can also be chosen as target stage, meaning the stage that the entity should be in once moved. If a similar structure is present on both modules, the stage will persist through the move, unless otherwise specified.

A useful case for this action is when completed projects should be moved to an archive business module upon reaching the some closed-state. This is usually done for performance reasons, but also for security reasons.

Below is shown the interface for creating a Move Entity Action:

The action requires a title, an active state, a target business module to move the entity to, and a target stage, which is the stage that the entity should be in once moved. It is important to note that in order to be able to select a target business module, there must be at least one business module present on the solution which has the same Module Group name as the source (the one currently being configured) It is also important to note that if a similar stage hierarchy exists on both the source and target business module, the entity’s current stage will persist throughout the move, unless otherwise specified in the Target Stage field.

This action will create an Office 365 group for the entity and connect it to a Microsoft Teams site as well. This is useful for project teams that like to work in the Microsoft Teams interface as opposed to directly in WorkPoint and/or other services. Note that whatever interface is used, documents and items are all stored in the same location  the WorkPoint/SharePoint libraries. This means that users can jump from working in WorkPoint to Teams and other services, but documents will always be easily accessible in the same locations as always.  

One use case could be instances where a specific project team wants to use Microsoft Teams to organize and work with their project. Perhaps because they are used to the Teams interface, or for some other reason.

Below is shown the interface for creating a Connect to Office 365 Group Action:

The action requires a title, an active state, information for the group’s alias, the display name, description, and whether the group should be public or private.

When this action is executed, an Office 365 group as well as a Microsoft Teams site is created for the entity. An email address for the Office 365 group is also automatically created, and the Group Alias is the first part of this email address, e.g. testEmail@domain.onmicrosoft.com. The Display Name is the name displayed on the Microsoft Teams site. The Description is not strictly required, but if a field is chosen, the information from that field will be shown as the description of the Teams site.

A Office 365 Group can be either public or private, and the state can either be fixed (not subject to change) or dynamic (based on a field value). A state of “yes” in the interface means that the group is public, and a state of “no” means that the group is private.

When a group is private, only approved members in the organization can see what is inside the group. In a public group, every member of the organization can see what is in the group. An example of the choices of the public-state is shown in the image below:

Note that there are two dynamic fields that can be used for setting the public/private state. These are so-called “yes/no” columns on the business module currently being configured.

This action will, as the name implies, change the Welcome Page of the solution. This is useful e.g. if the Welcome Page of a solution is dependent on changing properties of the solution.

Below is shown the interface for creating a Change Welcome Page Action:

This action requires a Title for the action, as well as a declaration of whether the action is active or not, and a page that will be set as the new Welcome Page.

When a "Notify WorkPoint365 Web Hooks" action is triggered in WorkPoint, it will also trigger the execution of a Microsoft Power Automate flow if the Power Automate flow trigger "Triggers when a WorkPoint event occurs" is used.

In practice, one would create an action of type "Notify WorkPoint365 Web Hooks" in WorkPoint 365 like so:

1. In the Action Management page in the WorkPoint Administration, select the "Notify WorkPoint365 Web Hooks" action in the drop down menu.
2. Click the "Add button".

3. Provide a title for the action.
4. Set the action to "Active".
5. Click the "Save" button.

6. Add the "Notify WorkPoint 365 Web Hooks" action to a trigger. In this case, we add the action to an already existing trigger, which also locks an entity.
7. Click the "Update" (or "Save") button.

In a Power Automate flow, we can use the "Triggers when a WorkPoint event occurs" trigger, to execute based on the trigger in WorkPoint 365:

8. In the Power Automate flow, we provide the "Triggers when a WorkPoint event occurs" trigger with the URL of the solution in question.
9. We select the business module for which the trigger is set up.
10. We select the trigger which contains the "Notify WorkPoint 365 Web Hooks" action.
11. Optionally, we can add a description for the trigger.
12. Now we can add more steps to the Power Automate flow to create functionality. This flow now triggers when the WorkPoint trigger is used to lock an entity on the "Projects" module.

For more information about using Microsoft Power Automate and PowerApps with WorkPoint, please visit this article.

This trigger executes an action upon the creation of an Entity.

This trigger executes an action whenever the stage of an entity changes. The transition that should trigger the action can be specified in the trigger creation interface.

This trigger executes an action when the user manually activates it, e.g. by clicking a button in the My Tools-panel.

An Entity Updated trigger is executed, when an Entity on a business module is updated. Normally the Entity Updated trigger is run based on conditions that are specified on the trigger. You can set up multiple conditions which must all be fulfilled, before the trigger is executed. The trigger is also only executed one time when all the conditions are fulfilled, if there is no “Any change” condition.

If no conditions are specified, the trigger is always run every time an entity is updated on the specified Business Module.

If the "Any Change" checker is enabled when adding conditions to the trigger, the system will check if the chosen field value has been changed, and if it has, it will execute the Trigger each time (if the other conditions is fulfilled as well)

If you combine multiple normal conditions with an “any change” condition, all the normal conditions have to be fulfilled, and the “any change” field has to have been changed before the trigger is executed. The trigger will execute every time the  “any change” condition has been changed.

Note that users should not be configuring Action Management unless they have received special training in how to use this feature.