Search

Why don't my changes to an incident get saved?

Environment:

Business Rules

Resolution:

When an incident automatically reassigns a field value when the agent saves the record, this is frequently due to how rules are configured for the site. If the incident remains in the initial state after it is created, then the business rules associated with that initial state will run against the incident each time that incident is saved.

Incidents remaining in the initial rule state may explain why certain fields are automatically reassigned each time the incident is saved. This includes fields such as the Queue, Assigned to, Status, and custom field values.

Note: This same behavior can occur with other types of records, including answers, contacts, opportunities, tasks, and organizations. If the rules for these records allow the record to remain in the initial state, records will be changed based on the rule configuration for the initial state -- even though the record is not newly created.

When a record matches a rule, it automatically continues on to be compared to the next rule in the list. If you want the record to stop being compared to the next rules in the list, you must include an action that either stops processing the rules, transitions the rule state and stops, or calls a function that has one of those actions.

If the record does not match a rule that includes an action to transition the state, the record remains in the initial rule state. This means that when the record is next updated, it is compared to the set of rules that you use to route and handle new records. As a result, for incidents, if your initial rules assign the incident to a particular queue or staff member, incidents that still have the initial rule state will get assigned in a similar fashion.

To troubleshoot why incidents or other records are automatically getting saved to other values, check the following items:

Check the Rule State for the Record

Verify that the record is associated with the correct rule state that should trigger the rule when the record is updated.  When a record is updated, it is compared to the rules for the state to which it is associated.

New records added to the site are assigned to the rule state that you set to be the initial rule state. The record is then compared to the rules in that initial state and may be transitioned to other states based on the rules they match. Then on future updates, the record is compared to the rules for the current rule state.

To determine the rule state for a record: Open the record for editing and hover over the information icon.  You can click the Info button or hover over it. Note that the fields listed on the Info button can be customized in the workspace.  If the rule state is not listed, review the configuration of the workspace you are using.  

Check the value of the Rule State field. If it specifies the rule state you have set as the initial state, then the record will always be compared to the initial rules, and fields will be set as though it were a new record being created in the system.

This frequently occurs with incidents and appears to the staff member that edits they make to certain fields are not being saved. Instead, the incident is typically hitting the rules used for initial routing, and those initial rules are reassigning fields, such as queues or the group or assigned to fields.

Null rule states:  If records are added via imports, such as contact records added using the Contact Uploader or records added from integrations, those records may have a null rule state.  If a record has a null rule state, when an update occurs the record will be assigned to the rule state that you set to be the intial rule state.

If you would like incidents with a NULL state to be assigned to a different rule state, activate the rule base to change this. When the rule base is activated, you will get a message indicating that there are X number of records with a null rule state. At that point, set which rule state those records should be set to and continue activating your rules.  The records will be set to the rule state but will not be compared to the rules for that rule state since the records were not actually edited or updated to trigger the rules.

Then, evaluate the process for importing those types of records.  Determine which rule state should be set when the records are imported or created and make that part of the import / creation process. That way, the records have the correct rule state so that when they are updated, the rules will act on the records as you expect.

Determine Which Rules Acted on the Record

Use the Rule Log to determine which rules have acted on that specific incident or record. To use the rule log, use the following steps:

1. From the Configuration items, select Site Configuration > Logs. Click the Rule Log button on the ribbon.
    
2. Set the Type to be Incident, enter the reference number in the ID field and click Search.

The rules that acted upon the record display in the search results. Now, you can review those rules to determine which actions or follow-on actions should occur -- including how best to transition the rule state for the incident.

For more information on using the Rule Log with other types of records, refer to Answer ID 1873: Using the Rule Log to Troubleshoot Rules.

Include an Action that Transitions the State

Somewhere in the path of the initial rules, each record should end up being transitioned to another non-initial state. For example, with incidents, follow the incident through the rules in the corresponding state and functions to determine where the incident finally ends up. At the point that the incident has hit all of the appropriate rules, that rule should include one of the following actions:

	Transition State and Stop -- the record is transitioned to the state but is not compared to any rules in that state. The next time the record is updated, it is compared to the rules in the state.
	Transition State and Continue -- the record is transitioned to the state and is then compared to the rules in that state.  So additional actions may affect the record due to hitting rules within the transitioned state.
	Call Function -- where the function leads to an action that transitions the state and either stops or continues.  That is, the function includes a rule that is hit and includes either Transition State and Stop or Transition State and Continue.

Therefore, when reviewing the rules for the record or incident that keeps getting updated, you must determine where in the overall set of rules you need to include the transition action.