use custom settings for setting Status field of different Case Record Type

Question

I am basically fishing for ideas here. I am a beginner, so i have a crude way of accomplishing task, but i would appreciate if someone experienced can provide some better ides.

Task - I have a custom button on Case. Clicking that custom button should change the case owner to current user. It should check the Record Type of Case, and if record type is one of the record types in group A (collection of some record types), Status of the case should be changed to "Working". If record type belongs to group B (another collection of some record types), status of the case should be changed to "In Progress", and if record type doesnt belong to either group, status should not be changed.

I am implementing it via a VF page. VF doesn't really open, it just invokes a controller which does all that. In the controller, i have managed to accomplish this in a crude way - stored case record types in sets, to see which category current case belongs to.

I am sure there is a better way to store all those collections of case record types in custom settings and use it in my apex code. No need to advise me on how to use apex to access custom setting ... that would be spoon feeding .. i will get that from developer guide. I just need some design inputs on custom setting.

Any kind of design would be helpful. Is there a way heirarichal custom settings be used? Or should i use List custom setting. Should i create one custom setting for each group of case record types? I want to make sure that in future, i dont have to modify my controller when another case record type is added to a group.

I barely started with salesforce and haven't really used custom settings. I have seen experienced developers use custom setting in clever ways.

Answer 1

Since the mapping from record type to status doesn't depend on who the current user or their profile is, and since there's more than one mapping at any given time, this is a better use case for a List custom setting (or custom metadata types, which have records that are visible to tests and deployable from your sandbox) than it is for a Hierarchical custom setting.

It sounds like your custom setting/custom metadata type would need one field in addition to the (standard) Name field, which could hold record type names: A Text field that would hold desired values for Status. Then in your controller, you could get the name of the record type off of the case and use it to look up the appropriate Status value. You could simply leave out record types where the value shouldn't be changed, and use the fact that the setting doesn't exist to determine not to change the value.

You just need one custom setting definition/custom metadata type for this. You'd probably want a record corresponding to each Case record type that implies Status should be changed (meaning there would be some duplication in values for your custom field).

So for example:

custom metadata type RecordMapping__mdt, which has one custom field, DesiredStatus__c:

Name            | Desired_Status__c
----------------|--------------------
Record Type 1   | Closed
Record Type 2   | In Progress
Record Type 4   | Closed
Record Type 6   | In Progress

This set of records would let you close cases of record types 1 and 4, would set cases of record types 2 and 6, and would not change the status of record types 3 and 5.

Answer 2

The hierarchy custom setting is for creating data that can be global to the entire organization, to specific profiles, or even specific users. Since that's not really the case, since you're trying to do something based on a specific record type, a list custom setting would be more appropriate. I'd advise storing specific record type IDs, meaning you'll need a way to convert the record type's label into an ID value; you can do this by way of a query, or using RecordTypeInfo, whichever you find more convenient. The list custom hierarchy returns a valid setting only if there's a match by name, so you can just check to see if there's a setting that matches the name of the record type, skip it if there isn't, or update accordingly if there is.