Customization of Case Creation Process With Triggers
Quickstart: Customization of Case Creation Process with Triggers
This is part of the Developing with Service & Support Quickstarts
Use Case
There are several ways that Case records can be created. An agent could create one manually, or features like Web-To-Case or Email-To-Case could be used to automatically create cases in response to end user communications. One of the common questions received from Service & Support customers is about how they can customize the process of case creation. Sometimes the need is to update a field value on new case records, or perhaps update or create a seperate related record. Other time customers want to send some kind of notification or manage how cases get assigned to agents and queues. There is a good solution to all of these scenarios: implementing a case trigger.
Background
A trigger is a custom piece of logic you express using Force.com's Apex programming language. This logic will be executed whenever a case is created (by whatever means), allowing you to perform any kind of action such as validation and field and record updates. Triggers can be set up to be executed before a record is created which gives you the opportunity to do some validation and if things aren't right, prevent the record from being created. In addition, you can set your trigger up to be executed after the record is created in which case you get a chance to read the field value from the case and perform any kind of update or notification based on them.
When you define a trigger you define three things. First, the name of the trigger - this is an arbitrary name you come up with. Second, the object to which you want the trigger to apply - here it would be the Case object. Lastly, which data events (insert, update, delete, undelete) you want the trigger to be executed before or after. Within the body of the trigger, variables called Trigger.old and Trigger.new are available which represent the collection of records before and after modification respectively. Generally you create a loop through one of the Trigger collections to perform your custom logic.
Sample Code: Trigger that validates cases upon creation
This trigger is set to run before every case is about to be inserted (created). It loops through the batch of created records and for each case checks that the Subject field is not empty. You could check any field value here obvisouly. If a problem is found with that record, then the addError method is called on the record which causes the insert to fail and the error to be returned. You could achieve this without writing a triggier but this example is used here to illustrate a very simple use case. The triggers below deal with more complex scenarios.
trigger CheckFieldValues on Case (before insert) {
for (Case c : Trigger.new) {
if (c.Subject == null) {
c.addError('Subject cannot be blank!');
}
}
}
Sample Code: Trigger that updates a field value before case creation
This trigger runs before case records are inserted. It checks to see if the Reason field is equal to 'Feedback' and if so, changes the Priority to 'Low'. This illustrates changing field values.
trigger UpdateFieldValues on Case (before insert) {
for (Case c : Trigger.new) {
if (c.Reason == 'Feedback')
c.Priority = 'Low';
}
}
Sample Code: Trigger that assigns cases to users based on product
This trigger assigns cases to users based on the product indicated in the case. A lookup is done to the User object where a custom field is used to indicate the product specialization of that user. That user's ID is then assigned to the OwnerId field of the case. Note that when performing queries within a trigger, you should avoid executing them inside a loop both for performance reasons and to avoid hitting Apex governor limits.
trigger UpdateFieldValues on Case (before insert) {
Map<String, User> agentsBySpecialty = new Map<String, User>();
for (User u : [SELECT Id, ProductSpecialty__c FROM User WHERE Profile.Name = 'Agent']) {
agentsBySpecialty.put(u.ProductSpecialty__c, u);
}
for (Case c : Trigger.new) {
if (c.Product__c != null) {
User u = agentsBySpecialty.get(c.Product__c);
c.OwnerId = u.Id;
}
}
}
Further Reading
This is just a quick introduction to triggers, check out the further reading links below for more information.
- Triggers Section in the Apex Code Language Reference documentation
- Autocreating A Contact From Web To Case Or Email To Case from the Service & Support blog
- Allowing Customer Portal Users To Edit Their Own Contact Information from the Service & Support blog
- An Introduction to Apex from the Core Resources section of Developer Force
- Apex page in the DeveloperForce Wiki
- The Force.com Cookbook downloadable book