Follow

Action Management

Contents

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.4. Types of Triggers

       3.4.1. Entity Creation Trigger

       3.4.2. Stage Change Trigger

       3.4.3. Manual Trigger

4. End User Guide

5. Notes

1. Introduction

Action management makes it possible to create jobs for the system to do (Actions) and define when to execute those 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 does not need to be kept with the active ones anymore, as performance of the solution can be impaired by the vast amount of entities in the Projects list. Normally, WorkPoint recommends less than 5000 entities per site, and the company is approaching this number in the Projects business module. They wish for the solution to be able to automatically move projects to an Archive module as 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.

2. Requirements

Using Action Management requires a purchased Action Management license. 

Contact WorkPoint Sales at sales@workpoint.dk for more information about how to acquire an Action Management license.

3. Configuration

   3.1. Example: Action with Manual Trigger

  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. The title is set.
  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 set.
  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:

   3.2. Example: Action with Stage Change Trigger

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 trigger is set to execute its action once a project changes stage from “Closed” to “Archived”.
  4. 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.

   3.3. Types of Actions

The following sections describe the available action types in WorkPoint Action Management.

       3.3.1. Item Creation Action

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. The coversheet can then be created based on the template, complete with all the necessary information pulled straight from the solution itself.

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

Based on that 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: <Where> <Neq> <FieldRef Name=”wpStatus” /> <Value Type=”Text”>Completed</Value> </Neq> </Where>

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.

       3.3.2. Lock Entity Action

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 easily rolled back, effectively reopening the entity 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).

       3.3.3. Unlock Entity Action

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.

       3.3.4. Create Site Action

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 the 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.

       3.3.5. Send Mail Action

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, an attachment can be added to the email by providing a document library for the attachment, as well as a CAML query to locate the file.

       3.3.6. Set Default View Action

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. Note that only views available on the selected list are selectable as View.

       3.3.7. Move Entity Action

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. 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.

       3.3.8. Connect to Office 365 Group Action

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 Microsoft 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 in this example 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, and custom ones, if created, are available here as well.

   3.4. Types of Triggers

       3.4.1. Entity Creation Trigger

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

       3.4.2. Stage Change Trigger

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

An example of the interface for creating a Stage Change Trigger is shown in the image below. This example shows different choices for which stage transition should trigger an action: 

3.png

       3.4.3. Manual Trigger

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

4. End User Guide

How the user uses this feature depends heavily on how it is set up. When action management is set up, it is typically set up to perform an action based on a stage change or as a manual trigger which executes upon a button-press from the MyTools panel. Examples of these two cases are described in sections 3.1 and 3.2.

5. Notes

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

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments