Update Actions

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

 

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.
• 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 Record Node

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

 

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

 

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:

$filter=[Supplier] eq {{Supplier}}

Where {{FieldID}} is the Parent App Field and [FieldID] is the Child App Field ID

Note: A more user friendly way of setting Filters is coming soon, for now entering Filters via string format is supported - See the bottom of here for information on string Filters.

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.

Compatibility Mode: A change has been made to copy and link so that now you can select what filters are applied to the link filter, previously the target filter and child app default report filter were combined together to make the final link filter. For newly created nodes you cannot select base filter combining and none of that UI shows -- you'll see only a target filter text box and only the target filter will be used. Historic nodes will show this selection:

• Combine target filter with default report filter snapshot: This is a snapshot of the child app default report filter that will combine with the target filter. This is is the way it worked historically so there where no changes to previously established workflow and you can make changes to the child app default report filter without effecting workflow.
  • Snapshot filter: $filter=[Field01] eq true
  • Child app report default filter: $filter=[Field02] eq true
  • Target App filter: $filter=[Field03] eq true
  • Final Filter Used: $filter=[Field01] eq true and [Field03] eq true

• Combine target filter with current default report filter: This combines the current child app default report filter with the target app filter, ignoring the snapshot filter. This is is the way it worked historically so there where no changes to previously established workflow and changes you make to the child app default report filter will effect workflow. Only the base filter from the defaultreport is used, other report types are ignored. If there is no default list report a base filter from a random report will be chosen
  • Snapshot filter: $filter=[Field01] eq true
  • Child app report default filter: $filter=[Field02] eq true
  • Target App filter: $filter=[Field03] eq true
  • Final Filter Used: $filter=[Field02] eq true and [Field03] eq true

• Use only target filter: This is a lot simpler, it will only use the target app filter in the workflow node and will ignore the default child app report and snapshot. We suggest using this at all times moving forward and updating all apps to this options if you have not already.
  • Snapshot filter: $filter=[Field01] eq true
  • Child app report default filter: $filter=[Field02] eq true
  • Target App filter: $filter=[Field03] eq true
  • Final Filter Used: $filter=[Field03] eq true

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:

$filter=([IsMaste] eq true and [Area] eq {{Area}})

Where {{FieldID}} is the Parent App Field and [FieldID] is the Child App Field ID

Date Fields comparisons require a format like $filter=[Date] eq datetime'{{Date}}'

Note: A more user friendly way of setting Filters is coming soon, for now entering Filters via string format is supported - See the bottom of here for information on string Filters.

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.

Compatibility Mode: A change has been made to copy and link so that now you can select what filters are applied to the link filter, previously the target filter and child app default report filter were combined together to make the final link filter. For newly created nodes you cannot select base filter combining and none of that UI shows -- you'll see only a target filter text box and only the target filter will be used. Historic nodes will show this selection:

• Combine target filter with default report filter snapshot: This is a snapshot of the child app default report filter that will combine with the target filter. This is is the way it worked historically so there where no changes to previously established workflow and you can make changes to the child app default report filter without effecting workflow.
  • Snapshot filter: $filter=[Field01] eq true
  • Child app report default filter: $filter=[Field02] eq true
  • Target App filter: $filter=[Field03] eq true
  • Final Filter Used: $filter=[Field01] eq true and [Field03] eq true

• Combine target filter with current default report filter: This combines the current child app default report filter with the target app filter, ignoring the snapshot filter. This is is the way it worked historically so there where no changes to previously established workflow and changes you make to the child app default report filter will effect workflow. Only the base filter from the default report is used, other report types are ignored. If there is no default list report a base filter from a random report will be chosen
  • Snapshot filter: $filter=[Field01] eq true
  • Child app report default filter: $filter=[Field02] eq true
  • Target App filter: $filter=[Field03] eq true
  • Final Filter Used: $filter=[Field02] eq true and [Field03] eq true

• Use only target filter: This is a lot simpler, it will only use the target app filter in the workflow node and will ignore the default child app report and snapshot. We suggest using this at all times moving forward and updating all apps to this options if you have not already.
  • Snapshot filter: $filter=[Field01] eq true
  • Child app report default filter: $filter=[Field02] eq true
  • Target App filter: $filter=[Field03] eq true
  • Final Filter Used: $filter=[Field03] eq true

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

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.

 

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:

$filter=([ClientID] eq {{ClientID}})

Where [FieldID] is the Parent App Field and {{FieldID}} is the Child App Field ID

Note: A more user friendly way of setting Filters is coming soon, for now entering Filters via string format is supported - See the bottom of here for information on string Filters.

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.