FAQs: Customizing Standard Modules

FAQs: Customizing Standard Modules

Customizing standard modules overview

What does customizing a standard module allow an organization to change?
Standard modules can be tailored through page layouts, fields, sections, field order, required-field settings, picklist values, layout permissions, and related-list display preferences. This allows different teams or processes to collect only the information that is relevant to their work.

For example, a support organization may use one Ticket layout for billing requests and another for technical incidents. The billing layout can require invoice details, while the technical layout can require product and issue information.
Which standard modules can use multiple page layouts?
Multiple page layouts can be used for:
  1. Tickets
  2. Accounts
  3. Contacts
  4. Activities
  5. Products
  6. Time Entries
The Contracts module does not support multiple layouts.
Why should separate layouts be used instead of one large form?
Separate layouts help reduce unnecessary fields and make data collection more accurate. Rather than requiring every agent or customer to navigate the same extensive form, each layout can present fields suited to a specific product, service, or process.

For instance, a warranty support ticket may need purchase date and product serial number, whereas a billing request may need invoice number and payment-related details. Separate layouts prevent both sets of fields from appearing where they are not needed.
How many layouts can be active in a standard module?
The maximum number of active layouts depends on the module:
  1. Accounts, Contacts, and Products: up to 20 active organization-wide layouts
  2. Tickets, Activities, and Time Entries: up to 20 active layouts per department
  3. Contracts: multiple layouts are not supported

How many fields can a layout contain?
A layout can contain up to 400 fields. This limit includes both standard and custom fields, regardless of their field type.

Before adding a large number of fields, confirm that every field supports a defined workflow, reporting need, or operational requirement. Excessive fields can make forms harder for agents and customers to complete correctly.
Does every department have a standard layout?
Yes. Each department has a Standard Layout for each module. It is the default layout and cannot be deactivated or deleted.

Administrators can rename and customize the Standard Layout, or clone it to create an additional layout. A different layout can then be configured as the department’s default layout where applicable.
Can the Standard Layout’s permissions and display preferences be changed?
No, The Standard Layout is assigned to all user profiles by default, and its permissions and display preferences cannot be modified. If different access or display behavior is required, create a new layout by cloning or adding a layout, then configure it for the appropriate user profiles.

Creating and Assigning Layouts

How is a new layout created for a standard module?
  1. Navigate to Setup > Customization > Layouts and Fields.
  2. Select the required module and department, when applicable.
  3. Click Add Layout.
  4. Enter the layout information:
    1. Name
    2. Help Center display name
    3. Description
  5. Select the user profiles that can access the layout.
  6. If required, enable the option allowing non-department agents with those profiles to access the layout.
  7. For Ticket layouts, choose whether the layout should be displayed in the Help Center.
  8. Click Save and Configure.
  9. Add and arrange the required fields and sections.
  10. Click Save or Save and Close.
Can a layout be cloned instead of created from scratch?
Yes. A layout can be cloned within the same department or across departments, provided both layouts belong to the same module.

For example, a Ticket layout used by Department A can be cloned for Department B, then updated with Department B’s picklist values, required fields, or field arrangement.
Can agents create records in any available layout?
No, Agents can create records only in layouts assigned to their user profiles. When creating a layout, administrators must assign it to the profiles that need to use it.
Can agents outside a department use a department’s layout?
Yes, if the layout is assigned to their profile and the administrator enables the option to allow non-department agents with assigned profiles to access that layout.
Can customers select a layout when submitting a ticket?
Yes. Agents and customers can select the appropriate Ticket layout while creating a ticket. Ticket layouts can also be made visible to end users in the Help Center.

This is useful when customers need to identify the kind of assistance they require before entering ticket details. For example, a customer might choose a Billing Request layout instead of a Technical Support layout.

Organizing Fields and Sections

Can standard fields be shown, hidden, or reordered in a layout?
Yes. Standard fields can be displayed, hidden, and reordered according to business needs, subject to system restrictions. Some mandatory, read-only, or system-defined fields cannot be removed.
To organize fields:
  1. Go to Setup > Customization > Layouts and Fields.
  2. Choose the required module and department.
  3. Select Edit Layout.
  4. Drag fields between the layout and Unused Fields to show or hide them.
  5. Drag fields within the layout to change their display order.
  6. Save the layout.
Can an organization hide a standard field from every layout?
Standard fields may be shown or hidden based on organizational requirements. However, mandatory, read-only, and system-defined fields cannot be removed from a page layout.

For example, a system-mandated field such as a Department or Contact Name remains available where required by the system, even if the organization wants a simpler form.
Can new sections be added to a layout?
Yes. New sections can be added to organize related fields into meaningful groups. Sections are useful for separating operational data from customer information, product information, or internal classification details.
For example, a Ticket layout could contain:
  1. Customer Information
  2. Product Details
  3. Issue Classification
  4. Resolution Information

Can custom fields be added to standard module layouts?
Yes. Layouts can include standard and custom fields. Custom fields can be created to collect industry-specific information, such as a referral source, product version, contract amount, or customer classification.

Custom fields are department-specific, so the same custom field configuration does not automatically apply across every department.

Required Fields and Field-Level Behavior

Can a field be required in one layout but optional in another?
Yes. Mandatory-field settings are configured at the layout level. The same field can be required in one layout and optional in another.

For example, a Purchase Date field can be mandatory for a warranty-support layout but optional for a general product inquiry layout.
How is a field marked as required?
  1. Open the required layout in the layout editor.
  2. Hover over the field.
  3. Select the Gear icon.
  4. Enable Mark as required.
  5. Save the layout.
A required field is identified by a red label in the layout editor.
Are ticket status values and picklist values configured at the department level?
No, Ticket properties including status values, picklist values, multi-select picklist values, and mandatory-field settings—are configured at the layout level rather than at the department or organization level.

This enables different layouts in the same department to use different field options and completion requirements.

Layout Rules and Conditional Experiences

Can layout rules respond to multi-select picklist values?
Yes. Layout rules can use a multi-select picklist field. This supports scenarios where a user selects multiple applicable topics and the layout needs to present additional information fields.

For example, a Service Topics multi-select field can allow a customer to select several subjects. If the selected topics require billing information, a layout rule can show a Billing Details layout or fields for the additional details.
Can layout rules use regular expressions?
Yes. Layout rule criteria can use:
  1. Matches Regex
  2. Not Matches Regex
  3. Contains Regex
For example, an administrator can use Matches Regex for an Order Number field to require an alphanumeric format such as ORD123. After the user enters a matching value, the layout rule can display the relevant billing details.
Can a layout show different fields for different products or service types?
Yes. This is one of the principal reasons to use multiple layouts and layout rules. Each layout can have different sections, fields, picklist values, and mandatory-field settings.
For example, a company supporting both software subscriptions and physical products can use:
  1. A Software Support layout requiring product version and environment.
  2. A Hardware Support layout requiring serial number and purchase date.

Field Dependencies and Data Quality

Can one field limit the values available in another field?
Yes. Field dependencies can create parent-child relationships between picklist fields. The child field displays only values that correspond to the selection in the parent field.

For example, after a customer selects a country, only the appropriate states can be listed. Similarly, selecting a product type can limit the available issue categories.
How are field dependencies configured?
  1. Navigate to Setup > Customization > Layouts and Fields.
  2. Click Fields Dependencies.
  3. Select the required module and department.
  4. Click Add New Dependency.
  5. Select the parent and child picklist fields.
  6. Map the permitted child values for each parent value.
  7. Save the configuration.
Why use dependencies instead of one long picklist?
Dependencies reduce irrelevant choices, improve consistency, and make forms easier to complete. They are especially useful when the valid secondary choice depends on the initial selection.

For example, a single issue-type picklist containing every issue for every product can lead to incorrect classifications. A Product Type parent field followed by a product-specific Issue Type child field provides more accurate data.