English
Frontline CRM · Objects · Interactive walkthrough

Configuring objects

Configure CRM objects so records, fields, relationships, and workflow context match the way the business operates.

Interactive walkthrough7 min
People table with real contacts, roles, companies, LinkedIn links, owners, email fields, filters, actions, and field counts
Product contextPeople table with real contacts, roles, companies, LinkedIn links, owners, email fields, filters, actions, and field counts

Use this product state to inspect customer memory: record identity, relationships, activity, and context that AI or workflows may depend on.

Visual operational blueprint

Learn the system by following the product states.

Use the screenshots as the primary map: start with the full context, trace the connected workflow, inspect the focused UI, then compare against the completed operating state.

People table with real contacts, roles, companies, LinkedIn links, owners, email fields, filters, actions, and field counts
Full contextPeople table with real contacts, roles, companies, LinkedIn links, owners, email fields, filters, actions, and field counts

Use this product state to inspect customer memory: record identity, relationships, activity, and context that AI or workflows may depend on.

01Record
02Relationships
03Activity
04Workflow context
05Max follow-up
Companies table with account-level customer memory and relationship context
Completed operating stateCompanies table with account-level customer memory and relationship context

This is the state to compare against when the system is configured, connected, or ready for review.

Summary

Configure CRM objects so records, fields, relationships, and workflow context match the way the business operates.

ProductFrontline CRM
ModuleObjects
CategoryObjects

Concepts covered

ObjectsObject configurationFieldsRelationshipsFrontline CRMOperational context

Step breakdown

  1. Open ObjectsStart in the Objects area and confirm what the real screen is showing.
  2. Inspect product behaviorUse screenshots and visible product states to understand what the screen does, why it exists, and how teams use it.
  3. Connect the platformSee how the screen connects to agents, workflows, records, activity, channels, integrations, or ownership.

What an object is

An object is a record type — People, Companies, Deals, and Tickets are the four core objects in Frontline. Each object has a defined set of fields, a relationship structure, and a set of behaviors that govern how records of that type behave in workflows and AI interactions.

Object configuration is not cosmetic. It controls what fields exist, which are required, what values are valid, and how records of that type connect to each other.

What configuration controls

For each object you can: add or remove fields, mark fields as required or optional, define picklist values, set field types (text, number, date, boolean), and configure which fields appear in record views.

Required fields prevent records from being saved incomplete. Picklist values prevent freeform entry that breaks workflow routing. Field types ensure AI can parse and use the data correctly.

How workflows use object configuration

Studio workflows reference object fields by name. If a field doesn't exist or its name changes, the workflow step that reads it will fail silently or return empty data.

Before building a workflow that reads or updates a record, confirm the fields it depends on are configured on the correct object. Treat object configuration as infrastructure — it needs to be stable before workflows that depend on it go live.

Designing objects around operational decisions

The best object configurations are designed around the decisions teams and workflows need to make, not around what information would be nice to have.

For each field you add, ask: does a workflow branch on this value, does Max use this when generating context, or does a human use this when deciding what to do next? If none of those are true, the field adds noise without operational value.

Operational playbook

Use Configuring objects as part of the Frontline CRM Objects operating loop: inspect the current product state, confirm the source context, and decide what should happen next.

The goal is not to memorize screens. The goal is to understand how the product surface supports repeatable work, AI assistance, and accountable handoff.

Best practices

Start with the operational job before changing configuration. Name the owner, define the trigger or source context, and decide how the result should be reviewed.

Prefer narrow, inspectable setups over broad automation. Teammates should be able to explain why the system took an action from the visible product state.

Troubleshooting

If the result does not match expectation, check the source context first, then permissions, connected integrations, required fields, workflow logs, and any AI-generated output used by downstream steps.

When in doubt, compare the latest product state with the related record, activity, or workflow execution so debugging starts from evidence rather than guesswork.

Validated CRM behavior

The real CRM surface lives under Work / Records with object routes such as People, Companies, Deals, and Tickets. People and Companies use list-style record tables; Deals and Tickets use pipeline columns for stage-based work.

Learning content should show the controls users actually see: List or Pipeline, Filter, visible-field counts, Actions, Add, row links, field columns, stage totals, and calculations.

Customer context checklist

Before acting on a customer, review the person or company, related deals or tickets, recent activity, ownership, and any workflow or Max-generated context.

The strongest CRM habit is relationship-first review: understand how the record connects before deciding what should happen next.

FAQs

What does Configuring objects teach?

Configure CRM objects so records, fields, relationships, and workflow context match the way the business operates.

How should teams use this lesson?

Use it as a product walkthrough: understand the real screen, the product behavior, the operational outcome, and how the area connects with the rest of Frontline.

How do CRM records improve AI workflows?

CRM records give Max and Studio shared customer memory: identity, relationships, deals, tickets, activity, and context that workflows can retrieve, summarize, update, or route around.

When should I create a relationship between records?

Create relationships when context should travel together: a person belongs to a company, a deal depends on contacts, a ticket affects customer health, or a workflow needs related records.

What should I check before changing the data model?

Check which workflows, summaries, views, and teammates rely on the field or relationship. Schema changes should preserve operational context and avoid breaking automation.

How should teams handle duplicate or incomplete records?

Prioritize records that affect active work. Merge or clean duplicates when they confuse ownership, customer context, workflow routing, or AI-generated summaries.

What makes CRM context trustworthy?

Trust comes from clear ownership, current activity, useful relationships, well-defined fields, and visible history. AI suggestions should point back to this structured context.