Update Actions – Softools

When setting up a Workflow, you will first need to set up a trigger event to determine when the Action will run. For a list of Trigger Events see our article here: Workflow Trigger Events

This article will focus on the Update actions, these are actions that allow changes to the state of the record you are in not just with in the app you are in but also parent and child applications

All Workflow Filtering is in NCalc Expression language.

Recalculate Expressions:

This node enables the updating of expressions through recalculating them in bulk. This means that whenever the workflow is triggered, all expressions in this record will be recalculated.

This will open a box, you do not need to select any fields or add any extra information - there is a notes section where you can add details.

Note: As this action re-runs every expression within the record, this workflow may not be suitable for records with lots of expressions as it may slow down the workflow.

Archive:

This option allows you to automatically archived a record, this can be used in scenarios were an action is completed it can then be archived

Ignore Access Rights: This setting ignores the access rights to records so the update can apply to all records and not just the ones the user trigger the workflow can access.

Set Full/Read-Only Access Rights: This option allows you to add security to records for teams or users, this can be useful for setting access based off location or ownership.

Target Teams: This will update the records access to all the Users in a Team selected from here. Multiple selection is made easier by using the arrow keys and hitting enter.
Target Person Fields: Using this option you can assign the access right to a User that is named in the Record in a Person Field. A typical example of this would to give a Full Access Right to an Action Owner on a Field Update when they have been selected as the assignee.

Target Current User: This will assign an Access Right to the User who triggered the Workflow. It is rare that this would be a Full Access Right but an example could be to lock down a Self-Assessment after the User has completed the Form. The User would initially be given a Full Access Right to the record to be able to fill in the Self-Assessment. Then on completion, meeting a Field Updated Trigger, a ReadOnly Access would be given by the Workflow.

Target Current User's Team: By targeting the Current User's Team it can give visibility to all Users in their Team of the work that they are completing. It could used on creation of a Project to give ReadOnly access to a User's Team when they create a new Project.

Note: If you would like to give some Users and Teams Full Access and some ReadOnly Access then this will need to be configured as two separate Workflow Actions. They can both be added to the same trigger however.

Note: This can only add access on top of default access, this cannot remove or replace access

Update field value node:

This node enables the updating of field values via an expression specified in the node configuration.

Target Field: When you click on it you will see a drop-down of all the possible options for the fieldS you can update. The fields that can be updated are limited to - Fields that are not static, not subfields, not autogenerated, no expression, not backing fields, and of the following types;
- Bit
- Date
- DateTime
- Email
- Integer
- Long
- LongText
- Money
- Notes
- Number
- Period
- Person
- PersonByTeam
- Selection (if SelectListType is Radio or Select)
- Range
- Team
- Text
- Time
- UrlDownloadField
- UrlField

Expression: This is where you enter in the expression that runs on the workflow to enter data into the field. Not all expression combinations will work right now but this will be expanded upon in the future. This is written in NCalc which you can find more about here.
Add Another Field Update: This option allows you to have multiple field updates in one action node instead of having to create separate nodes for each update
Ignore Access Rights: This setting ignores the access rights to records so the update can apply to all records and not just the ones the user who triggered the workflow can access.
Use Rolling Updates:If true, the data changed by an update specified in each action will be used to calculate the next update in this action; otherwise, the original data without changes will be used. Example below
- Say you do the following two field updates
  Target Field = A, Expression = "1 + 2"
  Target Field = B, Expression = "[A] * 4"
  If field A starts with the value -1:
  With "use rolling updates" enabled, A gets 3, B gets 12
  With "use rolling updates" disabled, A gets 3, B gets -4
Pass Updated Values to Following workflow actions: This option allow you to decide if you want these values to be passed onto another workflow actions that may have taken place from the same update.
Parameter conflict behaviour: This setting controls what happens when the value of a field referenced in the expression changes between the time the workflow is triggered and the time it is run.
Target conflict behaviour: This setting specifies what the workflow should do if the value of the target field changes between the time the workflow is triggered and the time it is executed.

Update child field value node:

This node enables the updating of child field values via an expression specified in the node configuration.

Target App: This will provide a drop-down option of all your child apps linked to the app you are in. You will need to select the child app that has the field you wish to update
Target App Filter: This filter will allow you to limit the child records you wish to update, for example, if you want to update all the actions on the child to a new update you will want to filter out all completed items to not be updated. This is written in NCalc which you can find more about here.
Target Field: When you click on it you will see a drop-down of all the possible options for the fields you can update. The fields that can be updated are limited to - Fields that are not static, not subfields, not autogenerated, no expression, not backing fields, and of the following types;
- Bit
- Date
- DateTime
- Email
- Integer
- Long
- LongText
- Money
- Notes
- Number
- Period
- Person
- PersonByTeam
- Selection (if SelectListType is Radio or Select)
- Range
- Team
- Text
- Time
- UrlDownloadField
- UrlField

Expression: This is where you enter in the expression that runs on the workflow to enter data into the field. Not all expression combinations will work right now but this will be expanded upon in the future. This is written in NCalc which you can find more about here.
Add Another Field Update: This option allows you to have multiple field updates in one action node instead of having to create separate nodes for each update
Ignore Access Rights: This setting ignores the access rights to records so the update can apply to all records and not just the ones the user who triggered the workflow can access.
Use Rolling Updates:If true, the data changed by an update specified in each action will be used to calculate the next update in this action; otherwise, the original data without changes will be used. Example below
- Say you do the following two field updates
  Target Field = A, Expression = "1 + 2"
  Target Field = B, Expression = "[A] * 4"
  If field A starts with the value -1:
  With "use rolling updates" enabled, A gets 3, B gets 12
  With "use rolling updates" disabled, A gets 3, B gets -4
Show Background Tasks: This option allows you to decide if you want to see any background tasks that may have been triggered due to the update. If the workflow will be updating a large number of records then we suggest turning this off to not clog up your notifications.
Parameter conflict behaviour: This setting controls what happens when the value of a field referenced in the expression changes between the time the workflow is triggered and the time it is run.
Target conflict behaviour: This setting specifies what the workflow should do if the value of the target field changes between the time the workflow is triggered and the time it is executed.

Update Record Node:

This node enables the updating of records. There are 6 options for updating records:

Link Records:

This action will look for all Child records that match a given filter criteria and link these Records to the Parent Record that the Workflow was triggered from.

To demonstrate this workflow we will look at an example of linking Contacts to a Supplier when a new Supplier Record is created. In this scenario, a number of Contacts have already been created and then a Parent Supplier App has been added that associates these Contacts to a Supplier.

Set Up: First select 'Update Record' as the Node and 'Link Records' as the Action.

Next select the Child App that you would like the Parent Record to find it's Child Records from (the 'Target App'). For our example we are adding the Workflow to the Supplier App and are Targeting the Contacts Child App to find Child Contact Records to Link. Next you will need to add the filter criteria that decides which Child Records are going to Link to the Parent:

Target App Filter: You can add multiple Field value criteria by using and (&&) / or (||) in a Filter String, in which case all defined criteria must be met in order for the Workflow to trigger. For this case when referencing both Parent and Child Apps the structure of a Filter String is slightly different, in this example it would be:

[Source.Supplier] = [Supplier]

Where and [Source.FieldID] is the Parent App Field ID and [FieldID] is the Child App Field. The source app is always the app that the Workflow is contained within.

There should be at least one Filter criteria that can be used as a match of values so the Parent Record knows which Children to Link.

Note: If no Target App Filter has been set then the workflow will link all child records.

Show Background Task Notifications : When linking records you my also be triggering workflow actions in the child as well, if this is done you will get notifications for all those tasks, depending on the amount of workflow and number of records being linked it could be 100s to 1000s of notifications, this options allows you to turn those notifications off so it doesn't clutter up you notifications area.

Ignore Access Rights: By selecting this it will mean that the User triggering the Event on the Supplier Record will not need access to the Contact Record in order for the Link to occur. If it is not selected then a Child Record will only link to a Parent Record if the User triggering the Workflow has Full Access to the Child Record.

Copy and Link Child Records:

This Workflow Action is similar to the Link Child Records Workflow but will make a Copy of the Child record to link to the Parent instead of Linking the original Record it finds in the Link filter.

A common use for this Workflow is to Copy and Link a set of master Child Question Records to a Parent Assessment on creation of the Assessment.

First select 'Update Record' as the Action and 'Copy & Link Records' as the Result.

Next select the Child App that you would like the Parent Record to copy and link Child Records from. We are adding the Workflow to the Assessment App and our Target App is the Question App to copy and link Child Question Records.

Then you will need to add the filter criteria that decides which Child Records are going to be copied and Linked to the Parent.

You can add multiple Field value criteria by using and (&&) / or (||) in a Filter String, in which case all defined criteria must be met in order for the Workflow to trigger. For this case when referencing both Parent and Child Apps the structure of a Filter String is slightly different, in this example it would be:

[IsMaster] = true && [Source.Area] = [Area]

Where [Source.FieldID] is the Parent App Field and [FieldID] is the Child App Field ID. The source app is always the app that the Workflow is contained within.

There should be at least one Filter criteria that can be used as a match of values so the Parent Record knows which Children to Link.

In our example we are only copying from a master set of Child Questions so our first filter criteria would be to narrow down the selection by this. We have stated that the Field 'Is Master?' in the Question App needs to be true. We can also filter down further by saying that a Field in the Child App needs to match a value from the Parent App. Our example says that the Assessment Area on the Child Question Record needs to match the Area stated on the Parent Assessment record.

Note: When copying and linking records from a master list of records it is important to not let the copied records join the master set. We can make use of a Template Copy which can exclude certain Field values from the Record copy to keep the master list clean. Here we would set a property on the Field 'Is Master?' to be 'Exclude(d) from templated record copy' and it will not copy the value of true but set it to false on copy of the Question.

Note: If no Target App Filter has been set then the workflow will copy and link all child records.

Now that we have set this up, when a User adds a new Assessment record, it will look for all the Master Questions in the Assessment Area chosen and copy and link that set of Child Questions to the Parent Assessment.

Ignore Access Rights: By selecting this it will mean that the User triggering the Event on the Assessment will not need access to the Question Records in order for the Link to occur. If it is not selected then a Child Record will only link to a Parent Record if the User triggering the Workflow has Full Access to the Child Records.

There are some further options that can determine the type of Record copy that is performed.

Templated Copy?: For each Field in an App you can set a property on the Field to 'Exclude This Field From Templated Record Copies'. If this property has been set for certain Fields and you choose to use a Templated Copy, it will not copy the values from these Fields when it copies the Record.

Copy Notes / Comments / Attachments / History?: These options provide you with a more granular choice of the Record copy that you would like. Notes will copy values from Notes Fields. Attachments and Comments will copy any that have been added to these areas of the Record. History will copy the Audit Trail for the Record, by not selecting this it will start the Audit Trail from the point the Record is Copied.

You can also choose to bring back a set number of Child records at Random from those that meet the Target App Filter criteria. To do this select 'Is Random?' and then choose the number of Child Records that you would like to be copied and linked.

Remember to click the 'Update/Add Action' button to save your workflow action, then to save the overall Workflow you must click the 'Update Workflow' Button.

Note: when a record is copied expressions are recalculated, this includes fields that have been selected as templated copies if there is a default value.

Link To Parent Record:

This is a feature that can be used when creating or updating Child records outside of the context of the Parent Record. Our example here will be creating a new Child Invoice and linking it to a Parent Client Record.

Create a new Workflow action and set 'Update Record' as the Action and 'Link To Parent Record' as the Result.

Note: The Link To Parent Record option will only appear if you are adding the Workflow in a Child App.

Next select the App that you would like the Child Records to find a Parent to link to. In our example we are adding the Workflow to the Invoice App and are Target App to find a Parent to Link to is the Client App.

Then you will need to add the filter criteria that decides which Parent the Child is going to link to. Specify this in the 'Target App Filter' box using the same method as detailed above. Here it would be as follows:

[Source.ClientID] = [ClientID]

Where [FieldID] is the Parent App Field and {{FieldID}} is the Child App Field ID. The source app is always the app that the Workflow is contained within.

There should be one Filter criteria that can be used as a match of values so the Child record knows which Parent to link to. In this case it's an alignment of the 'ClientID' Field in both the Parent and Child Apps, the logic checks to see of these are both equal to one another, if not then nothing will happen, the Child Record will remain stand-alone. However, if the two Field values are found to be equal the correct Parent is identified and the Child Record linked to it. You can add additional filter criteria if you need to. Once you have completed this click 'Ok' and it will add your filter.

What this now means is that a User can create an Invoice and enter the Client ID that it relates to. The workflow will then find the Parent Client record that has that Client ID and link the Invoice to it.

An additional option is to Ignore Access Rights. By selecting this it will mean that the User triggering the Event on the Invoice will not need access to the Client record in order for the Link to occur. If it is not selected then a Child Record will only link to a Parent Record if the User triggering the Workflow has Full Access to the Parent Record.

If we want this workflow to also run every time the Client ID is updated in case it changes on the Invoice, then we could add this workflow again with a Field Updated trigger as opposed to Record Created.

Note: If more than one Parent Record matches the filter criteria then the Child Record will link to the first Parent Record that it finds. A Child Record can only have one Parent Record

Inheriting Security: Copy and Link is a Copy then a Link
So for Record Copy

Access rights are copied when the Record is copied

For Link

Access rights are inherited from the Parent it Links to

So both the parent's security and the security of the master record will be on a copied and linked record.

Make sure to click the 'Save' button when making any changes in order for them to be added to the next app version. Once you have made all the changes you need to an application you are then ready to publish it to workspace.

Articles in this section