pretty common occurrence happens as you are setting up your Salesforce. You’ve got multiple teams/workflows using the same object, and their needs begin to step on each other’s toes. Maybe you have Account Managers and Sellers using opportunities, but you’ve got different stages, requirements, even page layout needs. Record Types to the rescue!
Implementing Record Types is easy to do, and also easy to get wrong. Should you? What are the reasons to use Record Types vs a picklist?
If you decide to use Record Types, three quick pieces of advice:
1) Share an Admin
Record Types are designed for independent behavior. But make sure there is someone (an admin in common, or at least a cross-functional team) who knows the needs of both teams, and make sure that that shared resource is consulted in any design choices and operational changes for either team. You should let the individual team leaders have unique and disparate processes and goals, but don’t fall into the trap of having tons of duplicated checkboxes that could be serviced by a shared picklist that could be dynamically customized for each record type / team. It’s incredibly easy to clutter pages with design by committee, and Salesforce by default suggests that new fields get added to both page layouts, so you’ll probably get cross-Record-Type-pollution if your admin isn’t accountable to both teams.
2) Design workflows linearly…
Remember that to have different Opportunity types, you’ll likely want separate Lead Record Types to avoid people ending up with the wrong type on conversion. Test lead conversion of each type to make sure this isn’t confusing when reps try to do it later. Where possible, make the Record Type layouts look obvious & distinct to the user, so they know if they’re looking at the wrong type of Opportunity. This linear design will reduce the chance that people mix up record types and make mistakes.
3) …but allow for team/type switching.
Next, consider when Record Type may be likely to change (while a Lead? Opportunity? Both?), and handle for it. Sure, there’s a default ‘Change Record Type’ button. But using it isn’t always that simple. For example, Record Types can allow you to specify different requirements for each type, either in the page layout or with validation rules. These requirements may break changing the type via the default button. For example, if the Record Type you’re changing to has a required field that isn’t in on the current Type’s page layout, this will make it impossible to change. Consider that these collisions will happen over time as validations and required fields change.
With anything, you have to weigh the tradeoffs of adding complexity. Record Types generally allow for more customization at the expense of making maintenance more time consuming and error-prone.
