We have around 50 record types on case. Soon we are going to merge our code with another instance where 20 more record types are present.

What will be the best approach to run my apex code, validation rules and flows on those 50 record types only.

I thought of creating a formula field on case returning true if the records types are of those 50, but within the code we are also changing the record type of the records so the formula field will be having old value until we query again.

Any suggestions? Whichever way you suggests, make sure it will work in flows and validation rules as well.

1 Answer 1


There's no easy way out of this. You'll have to review all of your existing automation and set up criteria accordingly.

In all of them make sure that RecordTypeId is not null. That's the first step. And then, might have a couple of options on how to approach this. I'm thinking that, if you long-term plan is to consolidate everything into a single instance, you will review all of that automation at some point:

Approach 1: Update existing records or new records

This will require you to review all of your automation. You might want to create a field to identify records of specific records types, like a Boolean or picklist field. And then you add that to the criteria of your automation in all Processes, Apex, Flows and Validation Rules you have.

Approach 2: Evaluate records as they are processed

This involves reviewing all of your automation as well. And is similar to the #1, but you'll have much more work because you'll be checking for the record type in each and every automation piece you have.

For Validation Rules especially this might be a challenge because you'll be checking the RecordType.DeveloperName for 50 different values.

To be honest, I'm with the opinion that you should review your org structure with your stakeholders and reduce the amount of record types you have on your object. Personally, I can't envision a scenario where 70 record types are necessary on an object. If we are talking about different layouts for those, remember that in the Lightning Experience's App Builder you can conditionally display sections and fields according to more flexible criteria (including formula fields), so that might be an alternative for you to build your layouts, if this is the case.

  • Actually why we created those records types is because every record type has different picklist. The status of the case also is different per record types so the path of working by agents for solving case will be different. Page layout is not an problem for us.
    – Sukruti
    Jul 27 at 12:16

You must log in to answer this question.

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