Articles in this section

Update Actions (Record Create/Update, Field Update, Copy and Link, Archive ect)

Avatar
Max Bateson
  • Updated
Follow

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 within the app you are in but also parent and child applications.

 

Recalculate Expressions:

This node enables the updating of expressions by 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: When adding this node to a scheduled workflow you need to make sure there is a filter node before it, this does not need to filter any actual records but just act as a gateway. For example, you can put in a filter the records will always meet the requirements i.e [Title] <> 'XXXXX'

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.

 

Record Create:

This facilitates the creation of new records in the same or a different app on the site. When the workflow is triggered, it can automatically create new records based on specified criteria and input data. This is particularly useful for workflows that require the generation of related records, such as tasks or follow-up items, when certain conditions are met.

Target App: This setting allows you to select the app within which the new record will be created. A dropdown list provides all available apps to ensure the correct destination for the new record. This app could be the current one or another app on the site.

Update Field: Here you specify a field in the app you previously selected and add an expression. This means that you can set a default value or a new expression-based value. This acts as a default initial value in the record, so the expression is processed only when the record is created and then is editable, so it's not a read-only field as expressions are usually in Softools. You can add as many update fields as you want to, with one being the minimum for the workflow to be saved

Note: You can reference the app that you are creating the workflow from by using the [Source.FieldIdentifier] option - this means that you can transfer a field value from within the current record to the new record that is created. - This is case sensitive, its needs to be 'Source'

Use rolling updates: This automatically switches on and means that any values that have been changed as part of this workflow will be accounted for in the expression/field updates for the create record node. If it is unclicked, then the expressions/field updates will not account for any previous changes in the workflow. So if the workflow also has an update field node, for example, that affects the new update field section of this create record node, then this will be accounted for if the toggle is switched on.

Link To Source Record: If you are creating a record in a child app this allows you to have the record automatically linked to the parent record from which it was triggered. T

Note: This happens after the record is created so any default value expressions with [Parent.FieldID] will not pull in a value on record creation.

Inherit source record access rights: This will mean that the new record created will have the record access rights as the record that this workflow is triggered from. So for example, if the record that triggers this workflow has security only for one user, then this user will be able to see the new record created.

Include target app default access rights: This will mean that the record access will be set from the default security set-up in the app that the new record is in. Therefore, the record will have the security dictated by the Security in App Studio.

Note: You can have both the inherent source record access rights and include target app default access rights toggled on together, which will mean that the new record created will have the security of both the record that the workflow triggers as well as the default security of the app that the new record is created in.

Target record owner: This will determine who the record owner is for the newly created record. There are three options – the current user, the source record owner, and a user from a person field in the current app.

  • The current user -This is the user whom the workflow is triggered by. For example, if the trigger node is a button click, whichever user clicks the button will be the record owner in the new record.

  •  

    The source record owner - This means that whoever created the record that triggers this workflow will become the record owner for the new record. For example, if a button is clicked to trigger the workflow from an existing record, whoever created that record (record owner) will now be the record owner for the newly created record not who triggered the button.

  •  

    User in person field - This means that you can select a person field that is in the current app of the workflow and this user will become the record owner for the newly created record. For example, you may have a person field which shows the approver of the current record and this approver will then be the record owner of the newly created record.

Note: If you select the User in person field option and there is not a value/user in the person field that you selected, then the Workflow will not run because the new record cannot be created without a record owner.

 

Archive:

This option allows you to automatically archive a record, this can be used in scenarios where 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 triggers the workflow can access.

mceclip1.png

 

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

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

 

Update Field Value:

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 the expression that runs on the workflow to enter data into the field. 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 allows you to decide if you want these values to be passed onto other 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:

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. Whenever you want to reference a field from the Source App (the app that the Workflow is in), you need to use [Source.FieldID]. 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 the expression that runs on the workflow to enter data into the field. Whenever you want to reference a field from the Source App (the app that the Workflow is in, you need to use [Source.FieldID]. 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 App Field Value:

This node enables the updating of field values in apps not linked directly to the Source App via an expression specified in the node configuration.

  • Target App: This will provide a drop-down option of all your apps. You will need to select the app that has the field you wish to update.
  • Target App Filter: This filter will allow you to limit the records you wish to update. Often this will be a unique identifier, like a project code for example. Whenever you want to reference a field from the source app (the app that the Workflow is in), you need to use [Source.FieldID]. It is written in NCalc which you can find more about here.
    • Note: Please make sure to add a filter carefully, if this is wrong and you have not tested then other records you do no wish to be updated could be updated.
  • 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. 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:

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

Link.PNG

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.ClientID1] = [ClientID2]

Where [Source.FieldID1] is the app you are in and [FieldID2] is the app you are look at.

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 may 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 a number of records being linked it could be 100s to 1000s of notifications, this option allows you to turn those notifications off so it doesn't clutter up your 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 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.

Copy_and_Link.PNG

A common use for this Workflow is to Copy and Link a set of master Child Question Records to a Parent Assessment on the 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 decide 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 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.

Show Background Task Notifications: When linking records you may 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 a number of records being linked it could be 100s to 1000s of notifications, this option allows you to turn those notifications off so it doesn't clutter up your notifications area.

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.

mceclip5.png mceclip4.png

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.

mceclip5.png

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 decide 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:

$filter={{Source.FieldID1}} eq [FieldID2]

Where {{Source.FieldID1}} is the app you are in and [FieldID2] is the app you are looking at.

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 if these are both equal, if not then nothing will happen, and 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 is 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. Selecting this will mean that the User triggering the Event on the Invoice will not need access to the Client record 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.

mceclip1.png

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.

 

Start Workflow:

This is used to trigger a workflow that is actions in a different application. A great example of this is where you may want to trigger a workflow asking for updates on a group of decisions that previously you would have had to go into each record and trigger, where now you can trigger all of those emails from the parent record they are linked to. For a video on this please click here.

Note: The apps do not need to be linked to trigger the workflows

Picture13.png

Target App: This is the app that contains the started by workflow trigger you wish to action

Target Node: This is the name of the node you wish to trigger in the app

Target Filter: This is the filter you would like to apply to the records in the app to decide which records should have the action triggered on.

 

Make sure to click the 'Save' button when making any changes 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.

mceclip0.png

Related articles

Comments

0 comments

Please sign in to leave a comment.