Industry CRM Builder

Lesson 1

Model the business language

Start with the nouns teams already use—membership, athlete, fixture, project or order. Create a custom object when the record has its own lifecycle, ownership or reporting value.

Identify which things have their own records and which are simply attributes. In a gym, a Trainer and a Membership can each have a lifecycle, while Membership Level is usually a picklist field. An Attendance object represents individual visits; it should not be a single multi-select field containing every visit on the member record.

Sketch one realistic example before configuring the object. List its required fields, owner, status and relationships. Ask how it will be created, updated, imported and reported. This helps avoid a large collection of fields that no team member knows how to maintain.

Lesson 2

Use lookups instead of duplicate text

A lookup lets users pick an existing related record and preserves referential context. It also makes filters, automation and cross-object reporting reliable.

A lookup stores a relationship to a particular record. It is useful when names change or when two records have similar display labels. An Attendance record can reference one member and, where relevant, a trainer. Users choose the existing target rather than typing another version of its name.

Test the relationship with two similarly named contacts and confirm that the selected identifier is correct. A Select field chooses one configured option; Multi-select chooses several configured options within one record. Neither creates multiple related records. Use an appropriate object and relationship when the business needs separate entries with their own dates or values.

Lesson 3

Design for the people doing the work

Show only relevant objects in BU navigation, then narrow each role to the actions it performs. Simpler navigation reduces training time and accidental changes.

Navigation and permissions solve different problems. Hiding an object keeps a team focused; permissions govern which records and actions the server allows. Define roles around actual responsibilities. A receptionist may need to create attendance but not change product pricing, while a manager may need reporting and correction rights.

Test each role using an account assigned to it, rather than judging access from the owner interface. In Users & roles, individual user permissions can inherit the role or explicitly Allow or Deny an action; custom objects have the same per-user exceptions. The BU owner keeps full access. Check viewing, creating, editing, importing and exporting separately. Include custom objects in the review and keep the number of people who can change roles or integration sources limited to those who need it.

Lesson 4

Evolve without breaking operations

Begin with the smallest useful model, test it in a Trial org and add fields only when a decision or workflow needs them. Blueprint installation is idempotent and remains editable.

Change a small part of the model at a time and test it with representative data. Adding a required field can affect record forms, imports and API senders. Changing a picklist needs an understanding of existing values. Renaming a display label should not be confused with changing the API contract used by another system.

Before publishing a business process change to your team, review affected forms, automation conditions, relationships and integration payloads. Keep a short record of why the change was made and how to check it. Reuse an industry blueprint as a starting point, then adapt only the parts your team will actually use.

Lesson 5

Field behavior and safe cleanup

Edit field labels and defaults in Objects & fields. For a dependent Select or Multi-select field, open Dependencies and choose an independent single choice field on the same object. If none exists, create the controlling field in that dialog, then select which dependent choices appear for each value and save. The record form shows only those choices; the API rejects mismatched values. Optional fields can be hidden always or shown when another field matches; required fields stay visible. Bulk deletion checks your role and uses each record's normal deletion protections, so linked or historical records may remain. Review the count and errors before repeating a batch.