Field configurations on dynamic forms

In some instances, it can be beneficial to create dynamic WorkPoint Automate processes which can be used across multiple business modules. One example could be an Update Entity process which can be used to update the metadata of both customers and projects within a given WorkPoint solution. Another example could be a Create Task process which can be used to create new tasks on both customers and projects.

The main benefits of having dynamic processes which are usable across business modules are that is can greatly reduce the number of processes needed on a solution, and maintaining workflows related to these processes is simplified as there are fewer processes to tweak when a change is needed.

This approach does lead to a problem related to Entity- and Item forms, in that the fields shown when configuring such steps are dependent on the business module selected in their respective "Business module" fields - something that needs to have a dynamic value for the process to work across multiple modules.

In this article we will describe how to deal with this problem in a way which makes it possible to use field configurations on forms used in dynamic processes.

The case we will implement as an example is outlined in the following section.

To exemplify the problem described in the introduction and to show how to solve it, we will work with the following case:

A customer has a WorkPoint solution containing three modules; Customers, Projects, and Contacts.

The Customers- and Projects modules have site enabled, and both contain a Task list with similar fields.

The customer would like a process for creating tasks on their Customers and Projects. The current user should automatically be set in the "Assigned To" field. The Start date should be set to today, and the "Due Date" field should always be set to 14 days in the future.

Lastly, each Task list contains a hidden field called "Task Responsible", which should likewise always be set to the current user.

These values may change, but are currently required to be those specified above.

To solve the aforementioned case, we will create one process which can be used on both the Customers- and Projects module. This process will use the following steps:

• An Item Form step
• A Create Item action step

We have already created the new process and added the Item form to it:

If we start by setting the process up to be dynamic, e.g., by using "BusinessModule.Id" and "Entity.ID" in the respective fields, the "List" field would not present us with an option to select a Task list, and therefore the form would not be able to display the available fields to us, making it impossible for us to configure the fields according to the case description. This is shown in the following image:

Initially, we therefore need to select one of the two business modules with a task list in the "Business module" field, which enables us to then select a Task list in the "List" field:

Upon selecting the Task list, the "List fields" section then shows the fields available on the standard provisioned Task list. Note that if the list contains hidden fields, these will also be shown, making it possible for us to pass information to and from those:

We can now make whatever configurations to the Task fields we need, in accordance with the case description:

Here we have configured the "Value" properties of the "Start date", "Due date", and the "Assigned To" fields as follows:

• Start date uses the following adaptive expression: utcNow()
• Due date uses the following adaptive expression: addDays(UtcNow(), 14)
• In the Assigned To field, we have simple selected the CurrentUser object from the context browser
• The hidden field "Task Responsible" has also been set to the CurrentUser object from the context browser

Now that we have made the necessary configurations to the fields on the Item form, we can change the value in the "Business module" field from e.g., the Projects module to the dynamic "BusinessModule.Id" property from the context browser:

As was shown previously, when a dynamic value is selected in the "Business module" field, the "List" field does not know specifically which lists are available and therefore cannot show the fields available either. This results in the List field instead defaulting to the "Lists/[Name of the list that was previously selected]", in this case "Lists/Tasks".

You will also notice that despite us having selected a dynamic value for the Business module, we actually do see a couple of fields in the "List fields" section, specifically the fields which we made configurations for.

Both Item- and Entity forms will always display fields which have been configured in one way or another, even if dynamic values are used in the other fields.

Also note that clicking the recycle bin for each field removes the field configuration from the form.

We can now add a Create item step, which will be responsible for creating the new task:

In the "Step Input" field, we select the output from the Item form, ensuring that the task is created using the metadata we provide in the form.

The Options for the step, we configure as follows:

Let's save and run the process, first from a Customer:

Here we have run the process from inside a Customer site, and we can see that the Start date, Due date, and the Assigned To fields have been correctly filled with the appropriate values (and we have added a title for the task as well).

The created task of course gets the metadata provided. Note that here, we have temporarily made the Task Responsible field visible, so that we can see that the current user was indeed passed into it:

The result, using the same process on a project, results in a similar outcome: