Record Types allow you to classify data in contacts, accounts, deals, and custom modules so users from different roles can consume and update data in the CRM in different ways. This is possible by having different field permissions and data scoping per record type per role. Based on the record type, administrators can also set up different types of follow-up processes or automations like workflows, sequences, auto-assignment rules.
For example, Acme is an architecture and home improvement company providing services to customers, who are looking for home renovation/architectural needs, through vendors offering such services.
A salesperson from Acme would cater to two types of customers - contacts and vendors. The information that the salesperson would want to capture for both contacts and vendors would be different. In addition, both types follow different business processes, eg: A workflow can be configured to trigger a profile page creation for confirmed vendors but no such process is required for customers. A sales sequence can be configured for customers for sending follow-up emails/SMS.
Let’s go through the details with an example
Sample fields for vendor type
Business service category
Sub-category
Company type
Website URL
Business description
Sample fields for customer type
Business service category
Sub-category
Project status
Time to start
Price level
Quality level
All of the fields listed above can be created under the Contacts module but only relevant fields can be selected for relevant types using Record Types configuration . Some fields can be common across one or more record types. So in the above example, business service category and sub-category should be marked ‘editable’ in both the contact types. Company type, website URL, business description should be marked ‘editable’ in Vendor type but ‘hidden’ in customer type and vice-versa for project status, time to start, price level, and quality level. This same type of configuration can be extended to a role level. For example, a marketing user need not have access to ‘quality level’ field in customer type but a sales user will require access.
How to create a new Record Type?
To create a new Record Type,
Go to Admin Settings > Teams & Territories > Roles > Choose a role. For example: Sales User
In the Record Types tab, choose the module for which you want to create a Record Type. For example, Contacts
Click Add contact type
In the ADD CONTACT TYPE overlay, give the Record Type a name, for eg. Vendor. You can select only those roles which need access to the new record type you are about to create. Administrator and Account admin roles will have access to all record types always.
Click Save. The Vendor record type is now created.
Record Types Scope
You can choose the scope of the record type for the role - Editable/Read only/Hidden from the drop down.
Editable - All records belonging to the vendor type will be accessible and editable.
Read only - All records belonging to the vendor type will be read only
Hidden - All records belonging to the vendor type will be hidden
Note:
Role Precedence for a Global/Territory/Restricted scope with a hidden record type: The Record type scope will take precedence as the user will not be able to see records with the hidden record type.
Field Permissions
On creation of a record type, field permissions will be fetched from the configuration set for the module (Admin Settings > Module settings). You can customize on top of the initial configuration by clicking on ‘Manage field permissions’ next to the Vendor record type
You can configure these field permissions per role per record type - Read-only, Hidden, Editable, Field choices, and Required.
Read-only: User can view the field value but cannot edit
Hidden: User will not be able to view the field
Editable: User can view and edit field values
Field choices: Choices for multichoice (dropdown, radio and multi-select) fields can be configured. For example: For the record type ‘Vendor’, you can select a new business category called ‘Exterior Painting’. But for the Customer record type, the choice ‘Exterior Painting’ can be hidden, until you onboard enough vendors.
Note: Choice selection is the same for all roles of a record type, and can vary for record types.
Required: Fields for a record type can be made mandatory/required. This means that if you haven’t marked a field as a mandatory field under module settings, you have the option to mark the field as mandatory at a role or record type level.
Click Save
Note: The admin should configure the field permissions for all record types and for all roles as explained above.
Module Settings vs Field Permissions
The following table will help you understand field behavior based on module settings vs role/record type configurations:
Category | ||
Field creation | You can create fields from module settings | You cannot create a field at a role or record type level. |
Field deletion | If a field is deleted at a module level, the field will not exist anywhere in the CRM | Field deletion is not possible at a role or record type level |
Field hiding | Fields hidden at a module level will not appear in forms. The hidden fields are accessible in other places in the CRM | Possible through field permissions and is applicable only to a record type and the corresponding role |
Required property | If a field is made mandatory/required at a module level, it will apply for all roles and record types and cannot be changed at a role or record type level | Fields can be made mandatory for a specific record type and role |
Quick Add | Fields that should be reflected in the quick add form for the creation of records can be defined at a module level | Quick add cannot be configured from field permissions |
Unique property | Uniqueness of a field can be defined only at a module level | You cannot mark a field as unique at a role or record type level |
Field dependency | Possible to configure through module settings. | Not possible through field permissions |
Order of dependent fields | Possible to configure through module settings. | Not possible through field permissions |
Values for multi-choice fields | Not possible to configure through module settings. | Possible to configure through field permissions. Choice selection is at a record type+role level. |
Group and subgroups | Fields can be grouped and subgrouped at a module level. The grouping will be reflected across the product - detail page, forms etc. | Fields cannot be grouped at a role or record type level. Module level grouping will apply to roles and record types. |
Field position | Position of the field in a form or group or subgroup can be defined at a module level | Field positions cannot be defined at a role or record type level |
Placeholder text | Possible to configure through module settings. | Not possible through field permissions |
Tooltip | Tooltips for fields can only be configured at a module level | Tooltips cannot be configured at a role or record type level |
Label and internal label | Field labels can be configured only at a module level | Field labels cannot be configured at a role or record type level |
Other properties like number formatting or formula definition | Number formatting and formula configuration can only be done at a module level | Number formatting and formula configuration is not possible at a role or record type level. |
Note:
Record types can be created for both default and custom modules.
You can add 25 Record Types per module.Where can you view the Record Type tag in the product?
Detail Pages
Record Types will appear on the details page of a record (both default and custom) and cannot be edited inline.
Note: If there is only one record type in a module, the tag will not appear.
Filters
Users can filter data based on the record types (editable and read-only types) and save them as list views or perform bulk actions on the filtered views.
Note:
1) You cannot inline edit/update a record type
2) You cannot bulk update record types
How can I edit a record type?
Go to Role > Record Types > Click the Ellipsis icon and click Edit
You can change the name of the record type and the roles that can access this record type in one go.
How can I delete a record type?
Under the record types tab on the roles page, click the ellipsis icon and click Delete
In the prompt that appears, you can migrate all the records with this record type to a different record type before deletion
What are default record types?
When the Record Types feature is enabled in your account, all the modules (contacts/accounts/deals/custom modules) will have a default record type. The default record type will have all the existing permissions that you have configured intact (both on a module and role level).
Admins can use the ellipsis icon to set a different record type as default.
Where will default record types help while creating records?
Records created through | Record Type |
Forms | The record type selected while creating the record through the Form. By default, the default record type will be in the selected state, which can be changed by the user. |
Classic Webforms | Record type selected in the webform |
Marketplace Apps |
|
APIs | If no value is passed via API, the fallback value will be the default record type of the user. |
Import | Record type field is supported for mapping during import. A detailed explanation on import can be found below in this article. |
Freddy duplicates merge | The record type of the record to which we are merging to. |
Journeys | The record type selected while creating the record through the Journey. |
Landing page builder | The default record type of the user who created the landing page. |
Incoming calls (From an unknown number and when ‘mobile’ field is unique) | The default record type of the account admin. |
Outgoing call | The default record type of the user who is making the call. |
Agent chat widget | The default record type of the user/agent. |
Bots | The default record type of the account admin. |
How do dependent fields work in tandem with Record Types?
Dependent fields can be marked as read-only/hidden from the field permissions page. Field permissions applied to one record type under a role will automatically apply to all record types under that role. However, the field permission can be different for other roles.
Scenario 1: For the sales user role, the Business subcategory field is marked as editable in Default contact type (default record type), read-only in Customer record type, and hidden in Vendor record type.
If Business subcategory is now configured as a dependent field under dependency settings, the permission for the field will be reset to ‘editable’ for all the record types in that role.
Scenario 2: If the Business subcategory field is marked with the same permission (editable/read-only/hidden) under all record types and is also configured as a dependent field, the selected field permissions under the sales user role will be retained.
Scenario 3: If the Business subcategory field is marked as required for Customer record type and is configured as a dependent field, the 'required' property under field permissions for all record types and all roles will be removed. In this case, the required property of the dependent field can only be defined from the dependency settings page.
Scenario 4: If the Business subcategory field's choices are selected through field permissions, and the field is also configured as a dependent field, then, the choices configured via field dependency will take precedence and will be reflected across all record types and all roles. Choice mapping link under field permissions will be disabled.
Scenario 5: If the Business subcategory field’s choices are selected through field dependency after which the dependency is disabled/deleted, the Manage choices link in field permissions will be changed to enabled state. And to start with, all the choices will be in the selected state.
Note:
1. Manage choices and required property under field permissions will be disabled for dependent fields as choices and required property of dependent fields can be configured only from the dependency settings page.
2. Editable, read-only, and hidden columns will be enabled for dependent fields. However, the permission for the dependent field will be the same for all record types under a role. It can be different for other roles.
3. Any required field cannot be marked read-only. This applies to all the scenarios where a field can be marked required - at a record type/role level or marked through field dependency or marked through form settings (module settings)
How to use Record Types while creating and updating records?
Forms
When you open a form to create a record, you can select the record type. The default record type will appear in the drop-down, which can be changed. The fields that appear in the form are based on the record type chosen. If the record type is changed, the form will reload to reflect the new record type.
Users can create records under a specific record type if their role has edit access to the particular record type. For example, If there are five record types in total, two of which are editable, one in read-only state and the other in hidden state for a sales user role, sales users will only be able to create records on the two editable record types. The read-only or hidden record types will not appear in the form.
You cannot change the position of record types in the quick add form (from the top), as the fields in the forms load based on the record type chosen.
An existing record type of record can be updated from the Edit form
During Import
In the first step of import, you can choose a fallback value for the record type.
By default, the default record type of the user who is importing the records will be in the selected state. Users can choose a different record type to which they have access.
Fallback record type is used if your csv/xlsx file does not have a record type column or if the values under the record type column are null or invalid.
In Step 2, users can map the record type column present in the csv/xlsx file to the record type field in the CRM. All required fields in each record type will have to be filled. For example: If there are 3 record types with 2 required fields each, then during import, the user has to map 6 required fields that will apply for all the records that are being imported
Note: Only editable record types for the user/role show up in the import flow. Read-only and hidden fields do not appear.An existing record type of record can be updated via Import through overwrite
How field permissions apply in the CRM
List page filters | If any field has read-only or edit permission in any of the accessible record types, that field will be available for filtering. If a field is hidden for all accessible record types, that field will not be available for filtering. |
List page | If any field is read-only for a record type, the field value cannot be edited for records belonging to the respective record type. If any field is hidden for a record type, the field value will not be displayed for records belonging to the respective record type. |
Column customization | If any field has read-only or edit permission in any of the accessible record types, that field will be available for selection. If a field is hidden for all accessible record types, that field will not be available for selection. |
Detail page | Field permissions of the specific record type to which the record belongs to will apply. |
Import | If any field has read-only or edit permission in any of the accessible record types, that field will be available for mapping. If a field is hidden for all accessible record types, that field will not be available for mapping. |
Workflows | If any field has read-only or edit permission in any of the accessible record types, that field will be available under conditions. If a field is hidden for all accessible record types, that field will not be available under conditions. |
Auto-assignment rules | If any field has read-only or edit permission in any of the accessible record types, that field will be available under conditions. If a field is hidden for all accessible record types, that field will not be available under conditions. |
Sales sequences | If any field has read-only or edit permission in any of the accessible record types, that field will be available under conditions. If a field is hidden for all accessible record types, that field will not be available under conditions. |
Webforms | Field permissions of the record type selected while creating the webform will apply. |
Email templates | If any field has read-only or edit permission in any of the accessible record types, that field will be available as a placeholder. If a field is hidden for all accessible record types, that field will not be available as a placeholder. |
Analytics - Fields | If any field has read-only or edit permission in any of the accessible record types, that field will be available in reports. If a field is hidden for all accessible record types, that field will not be available in reports. |
Segments | If any field has read-only or edit permission in any of the accessible record types, that field will be available for filtering. If a field is hidden for all accessible record types, that field will not be available for filtering. |
Journeys | If any field has read-only or edit permission in any of the accessible record types, that field will be available under conditions. If a field is hidden for all accessible record types, that field will not be available under conditions. |
Landing page builder | All fields in the module irrespective of role based field permissions will be available for configuration. |
Contact creation through chat | Field permissions will be bypassed while creating the contact |
Other pointers on Record Types:
Field dependency - Choices can be controlled only from one place. Other properties of a dependent field will stay the same for all record types for a role (can differ between roles). Required property can be controlled only from field dependency for dependent fields.
Record type field will not be available in field settings.
Record Types cannot be edited inline or in bulk. Record Types of records can only be edited through the overwrite option via import.
Record types field is not available as a controlling or dependent field.
Admins and Account admins can now edit field permissions
There are no record types for the products module.
If there is only one record type and a field is marked as required for a role through field permissions, it is automatically marked as required in the form settings too for a user logged in with that role.
If there are multiple record types and a field is marked as required even in one role, the field will always be available in the Quick add form for other roles too.
Manage choices is a record type level configuration and not at a role level, i.e., choices configured for a particular record type will be the same for all roles.
Choice selection is honored only in the UI, not in API.
If there is only one record type in a module, permissions cannot be changed (non-editable state) for administrator and account admin roles. ‘Manage choices’ and ‘Required’ properties will be in a non-editable state for other roles.