2

Is it possible to create a work flow or trigger on changes in a custom setting or a record type?

The problem I'd like to address is that I have a custom setting that maps some Account record types to certain actions when a record is created or updated. This manages record ownership and rolls to several custom objects as well. The problem I'm having is that the admins sometimes change the record type names for Accounts that should be maintained but forget to change the custom setting so that the code will know to maintain these records. I'd like to create a trigger, or if I can simplify the logic, a work flow rule that notifies the admins to also correct the custom setting. I might even like to send a notification if a new record type is created to ask the admins if this should also be a managed record type.

Is this even possible?

2
  • Why don't you create a trigger for Account object where you will check if 'record type name for Accounts' was changed and send e-mail notification? Feb 10, 2014 at 14:42
  • They like to complicate things and they manage the ownership of several objects based on the record type. This has to do with pay for sales people so it is a touchy subject and though I've created things to work the way they've required, they forget the ramifications of creating new record types and changing names at a whim. They also like to change things a lot thus the reason for using custom settings. Feb 10, 2014 at 15:36

1 Answer 1

2

Your custom setting should keep track of the recordType.Id, not the RecordType.Name. This way the admin could change the name indiscriminately with no affect to the code.

4
  • That would be one way but it would be nice to have things stay consistent. Maybe I'll change it to that but I'd still like to handle when a new type is created to make sure they address things. Feb 10, 2014 at 15:33
  • One of the reasons I don't like to use the ID is that the ID changes from org to org where names would remain consistent. Using the ID's, in my experience, has been more problematic because you can't transfer the data from org to org and guarantee the ID's will be the same. Using names is simpler unless someone changes the names. Our production path runs through multiple orgs before finally making it to the live production org. Using ID's has been a major problem in the past. Feb 10, 2014 at 21:49
  • The id may change from org to org, but the main advantage is that the id will NEVER change once in an org. Users can muck around with the name all the want. It should really be part of your migration process to check these ids with each migration. In addition, the id does stay the same when doing a full data sandbox refresh, so you would only have to change it when migrating between orgs where the custom setting does not exist.
    – willard
    Feb 13, 2014 at 20:57
  • Willard, I agree with your point but using the name is less prone to error when promoting settings. With names, I can set up a CSV that can be imported into the object where if I go by the ID, the admin has to remember to set the IDs for all of the settings. I think this is a case of which sword you want to die on. Feb 14, 2014 at 16:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .