Cookbook

Model something the CRM has never heard of

Every business has a thing its CRM has never heard of. Describe it in a sentence and your workspace grows a real object for it, with real columns.

The situation

Companies, contacts, deals, tasks. Then there is the thing you actually run on, which depends entirely on what you do: campaigns, shipments, requisitions, matters, properties, trials. In most CRMs it becomes a text field called Notes, or a spreadsheet nobody links.

What must be true when you are done

The thing exists as its own type, with its own identifiers.
Its fields are typed and enforced, not free text you hope stays consistent.
Your agent can list, filter and write it exactly like anything else.

Describe it

You

We run marketing campaigns and I want them in here. Each one has a channel, which is email, event, paid or partner, and a spend. Give them a cmp prefix.

Agent

created campaign channel enum(email, event, paid, partner) spend number

That is a real type now. Records get identifiers like cmp_01M0RY..., so an identifier says what it is without a lookup, and the schema your agent reads lists it beside the built-in types.

Use it like anything else

You

Add the trade show we did in March, event channel, four thousand eight hundred spend.

Agent

created cmp_01M0RY8H2K... 2 fields

Listing, filtering and sorting work the same way they do on a deal, because it is the same machinery. There is no second grammar to learn for your own types.

The typing is real

A channel that is not one of yours is refused rather than stored, which is the difference between a typed field and a text box you were disciplined about.

You

Add one for the carrier pigeon campaign.

Agent

refused: not one of the options this field allows options: email, event, paid, partner

Six months in, this is what makes "spend by channel" a question with an answer. The alternative is four spellings of "e-mail" and a report you cannot trust.

What your own types do not get

One thing, and it is deliberate. Indraft never decides that two of your records are the same one: for companies and contacts it matches on a domain or an email address, and your own type has no equivalent. Two campaigns with the same name stay two campaigns.

You can still merge them by naming both, which is the same rule the built-in types follow. What is missing is the guessing, and it is missing on purpose: guessing wrong on a type the product knows nothing about is how you lose a record.

Verify it

Ask for the schema. Your type is listed with its fields and its prefix, which is how your agent learns it exists.
Ask for something impossible. A value outside an enum should be refused and should name the options.

Run it again

Once per thing, and rarely after that. Adding a field later is a normal change; the type itself tends to be right the first time, because you already know what you run on.