(Automatic changes were previously called 'Dynamic Field Changes' in pre-v8 Claromentis versions)

Automatic changes use triggers to change the value of a field in a form.

The most common usage is to automatically change the status or assignee of a form when a trigger is fired.

Automatic changes are really helpful to automate certain parts of your forms workflow so that this does not have to be manually undertaken by the submitter or other project role.

Adding an Automatic Change

A trigger needs to be set up first before the automatic change can be added.

Once the trigger has been created go to Admin > Infocapture > (your project) > Automatic Changes

Select the field you wish to change automatically and click 'Add rule for this field':

Now select the trigger that will decide when this change will be made. 

Next, choose what the value of the field needs to change to.

Click Add/Change rule to save.

Now whenever the trigger fires, the system will automatically enforce the change e.g. changes the status, assigns the chosen user etc.

Remember: Set up a copy version of any important forms on your site to allow your intranet management team to test new updates, like automatic changes, without disrupting the live form.

In Practice

Below are the two most commonly configured scenarios, either separately or in tandem however, you can use automatic changes however they best fit your form, play around and see what fits your requirements the best!

Automatic assignment of a user (the ticket handler)

In my form, whenever the 'Location' field is filled out as 'Brooklyn' I want it to auto-assign to user 'Matthew Brown' as he will be dealing with all their tickets.

1. Create a field condition that specifies Location = Brooklyn
2. Whilst creating the field condition, select a trigger to be created for it too:
   
   
    
3. Add a new automatic change for the 'Assigned to' field 
4. Choose the trigger just created for Location = Brooklyn
5. Set the new value to be 'Matthew Brown'
   Note: In order for a user to appear as selectable in auto ticket assignment users must have the 'handle tickets' permission in via their project role.
   
   
    
6. Test the form by submitting a ticket and firing the trigger, the ticket should auto-assign to Matthew Brown on saving.

Automatic status change

In my form, whenever the checkbox field for 'Needs approval?' is filled out I want the status of the ticket to automatically update to 'awaiting approval'.

1. Create a field condition that specifies 'Yes' in the 'Needs approval' field and give it an appropriate name
2. Whilst creating the field condition, select a trigger to be created for it too
   
   
    
3. Add a new automatic change for the 'Status' field 
4. Choose the trigger just created 
5. Set the new value to 'Awaiting approval'
   Note: Ensure the status you want to automatically change to has already been created in the project, otherwise it won't appear as selectable
   
   
    
6. Test the form by submitting a ticket with 'Needs approval' as 'Yes', the ticket should auto-update to 'Awaiting approval' on saving.

In this situation based on the automatic changes set up if a ticket was submitted that had 'Location' as 'Brooklyn' and the 'Needs approval' checkbox was also ticked, then it would auto-assign to Matthew Brown and the status would update to 'Awaiting approval' too.

Therefore once you are building out your automatic changes consideration is needed to ensure any conflict or overlap will result in the ticket behaviour you want to see and if not, tweak either the form logic or your own requirements as necessary.

Consider all stages of your form's workflow and brainstorm with your team to see if any can parts would lend themselves to automation and test thoroughly before implementing this on a live or established form.

Over time, continue to add in any other relevant assignees or status changes using the 'add rule' button and build up a table of automatic changes:

Watch out for conflict

If your form is going to use a lot of automatic changes, or there is going to be some overlap in the conditions used within them your team need to be aware of the order they are processed as this could impact how your form behaves.

If there is any conflict trying to apply the automatic change, the system will apply the last processed relevant rule, as it reads these from top to bottom.

Therefore if multiple conditions are true when a ticket is submitted that match more than one rule in your automatic change table, the system will resolve the conflict by applying the rule lowest in the table.

This is something to watch out for if you are seeing users or statuses you do not expect to be automatically applied, it's likely due to conflict created by the field conditions used, the order of the rules and how they apply to that particular ticket.

Solutions are to:

1. Rework your automatic change rules 

Remove the conflict so that the conditions used in automatic changes no longer overlap, allowing all rules to fire independently and be applied.

2. Move desired changes that have conflicts lower in the table

Ensure the system applies them as they are the last processed relevant rule for that ticket.

Use the arrows to move rules up and down

Automatic changes on submission

If a ticket is configured to assign to a user or change status via an automatic change at the point of submission, the updates will not be recorded in the history tab.

Instead, the system will show who was assigned before, or what the status was changed from when a second operation is made.

This is something to be aware of when looking at newly submitted tickets, the front-end elements that show who is assigned and the current status should be referred to and not the history, as this will only reflect 'New ticket'.

Once a second change is made, the history will show the previous entries, that were only visible on the front end of the ticket or in the assigned to and status field beforehand:

Recommended next article:
SLA