When is it appropriate to use Record Types?

Question

The documentation for Record Types states:

Record types allow you to offer different business processes, picklist values, and page layouts to different users.

It seems to me that unless you are going for the first option (different business processes) that Record Types actually end up being more trouble than they are worth.

---

Scenario:

There are 2 sales teams, for simplicity I'll call them Sales Team A and Sales Team B.

• Sales Team A and Sales Team B should both be able to see and edit the same Accounts & Contacts.
• Each team has a set of fields that is specific to them.
• Each team also has values that are specific to them in picklists that they both use. e.g. the Account 'Type' standard field, these picklists only have one valid value for a given account.
• There are also some picklists where both teams will have different values they need to enter e.g. a custom 'Type Code' field, when Sales Team A looks at the record it should show 'A1' when Sales Team B look at the record it should say 'B3'.
• Sales Team A and Sales Team B have different profiles (for other reasons outside of the scope of this).

Solution 1 (Record Types):

• Create 2 Record Types, one for Sales Team A accounts and one for Sales Team B accounts, setup the picklist values in each Record Type and create appropriate Page Layouts for each of them.
• Assign Sales Team A the Sales Team A Record Type in their Profile, and Sales Team B the Sales Team B Record Type in their Profile.

Problems:

• If Sales Team A creates an Account, Sales Team B can view it, but as it is a Sales Team A account they cannot select the picklist values that are relevant to them in the common picklists e.g. 'Type'.
• In addition, for the picklists where they need to see different values e.g. the 'Type Code' field, if they change the value it will overwrite the Sales Team A value.

This results in Sales Team B setting up their own account record and therefore duplicate records on the system.

Solution 2 (No Record Types):

• Create 2 Page Layouts, one for Sales Team A and one for Sales Team B.
• Assign Sales Team A the Sales Team A Page Layout for the --Master-- Record Type in their Profile, and Sales Team B the Sales Team B Page Layout in their Profile.
• For the picklists that have separate values they will be separated into a Sales Team A field and a Sales Team B field with the same label, e.g. the 'Type Code' will become 'Sales Team A Type Code' and 'Sales Team B Type Code' both labelled 'Type Code', with the appropriate field added to the appropriate Page Layout.

Problems:

• For the picklists that they share but only want to be able to enter certain values, e.g. the 'Type' field, they will instead see all values and have to select the one that is appropriate,
• 'Duplication' of fields, e.g. the 'Sales Team A Type Code' and 'Sales Team B Type Code' which adds an admin overhead. Although I'm on the fence as to if these are actually duplicates, since it feels like they are actually separate fields.

---

In my opinion Solution 2 seems to meet the requirements whilst causing less problems. However, based on the documentation it is trying to solve 2/3 problems that Record Types are intended for so Solution 1 should be more suitable.

Am I misunderstanding the purpose of Record Types, or is Solution 1 a naive implementation of Record Types and they are ways it could be improved to resolve the problems noted?

Is there a better way that this situation could be modelled within Salesforce?

Answer 1

Record types are primarily used when you want to identify or "group" records that are used for a similar purpose or where its beneficial to identify them as being "related" or "similar".

Your question covers more than just record types. It also addresses how they can be utilized in terms of file sharing, restricting basic CRUD and impacting profiles. Your question interrelates all these issues.

Solution 1 assumes the need for two record types when perhaps there's only a need for one? Why do I say that? It appears to me that you primarily want to identify the records that either "belong" to or were "created by" Team A. Is that the case? After all, Team B can edit anything created or owned by Team A. So does Team B need their own record type? That's not totally clear yet.

As we know, there are often many ways of doing things in SF. I think there's an option that might suit your needs which you've not yet considered and that's Publisher Actions. You could have a Publisher Action that creates a new account based on the requirements needed for Team A and another Publisher Action based on the requirements needed for Team B. Both could use the same page layout, but only Team B Profile Users could also edit not only records created with the Team A Publisher Action, but also those created with the Team B Publisher Action. For those users with a Team A Profile, all fields they can't edit, would be read only unless you wanted them to have their own page layout appropriate for their profile.

Unless I'm mistaken, you could utilize record types for the above if you want to, or have new records default to the appropriate Publisher Action for the User Profile accessing the page. Whether to use record types really depends on whether or not there's a valid reason to segregate or "denote" a difference between records created by the two different teams and who has edit access to them.

I hope this answer is helpful to you. For more on this, I highly recommend you refer to Force.com Platform Fundamentals.