Skip to main content

CRM settings

CRM → Settings holds what the CRM does on its own, for every site in your workspace. A setting here is a fact about how your business files people, not about one site, so it is stored on the workspace and applies wherever a contact is captured. The section lives in the CRM hub at …/hosts/{site}/crm/settings, last in the rail, and at the organization level at …/{organization}/crm/settings, where it also holds the Recipes card.

Changing a setting takes the Change CRM settings permission, which owners and admins hold by default. Everyone who can open the CRM can read the page; a member who cannot change a switch sees it disabled, with a note naming the permission. Two cards are exceptions: the Email templates card, which every CRM editor may write to, because a template is working material, not policy; and Your sending addresses, which is each member's own list.

Companies​

Create companies from work email domains​

Off by default.

A contact captured with a work email address — a form submitted from jane@acme.com, a booking, an order, a sign-up — is linked to the company whose domain is acme.com the moment the contact is created, provided exactly one such company is visible to the capturing site. That happens whether this switch is on or off; see Companies — Linked on capture.

The switch decides what happens when no company carries the domain:

  • Off — nothing is created. The contact waits for somebody to pick or create the company from their record, or for the company to be created from the Companies list, after which the next capture at that domain links on its own.
  • On — a company is created from the domain, named after it (acme.com becomes Acme, initech.co.uk becomes Initech), with the domain filled in and the new contact already linked. It is created in the same scope the contact landed in — the sites that present as one sender, or the whole workspace when the workspace shares its data — so a site never sees a company it could not see the contact for. Rename the company, add its owner and address, from its own page.

Addresses at a public mailbox — Gmail, Outlook, iCloud, Yahoo, Proton and the like — never create a company and never link to one, on or off. A consumer list is not a list of accounts, and a company called "Gmail" with half your contacts at it is the one thing this setting must never produce.

A contact the CRM already knows — a repeat form submission by somebody in the address book — is not linked again. A contact added by hand with a company picked, or imported with a company column, keeps the company you chose; the domain is not consulted.

Default owner​

Who gets the contacts captured on this site when no assignment rule claims them. Pick a member of the workspace, or Nobody — leave unassigned, which is the default and is what the CRM did before the setting existed.

The default is per site — an agency workspace gives each client's site its own rep — but it is stored on the workspace with the other CRM settings and changed from any site's Settings section for that site.

A contact captured on the site — a form submission, a sign-up, a booking, an order, a newsletter capture — that no rule claims is handed to the default owner the moment the contact is created, and they get a console notification (Contact assigned to you, or Lead assigned to you when the site filed a lead for the same person, linking to the record they will work). Only a new contact is assigned: a repeat visit by somebody the workspace already holds changes nothing, and a contact added by hand, imported with an owner column, or converted from a lead with an owner picked keeps the owner you chose.

A default owner who later leaves the workspace is shown as a former member and assigns nobody until you pick somebody else.

Assignment rules​

An ordered list of rules tried, top to bottom, for every new contact captured on any site in the workspace. The first rule whose every condition holds assigns the owner; a contact no rule claims goes to the capturing site's default owner, or stays unassigned. Rules are what a sales team sets up first — bookings to one rep, a partner's domain to another, everything else in turn.

Add rule opens a drawer with four optional conditions and a target:

ConditionMatches when
SourceThe contact came in through that door — Form, Booking, Customer (an order), Member (a sign-up), Newsletter, API, Import, or Added by hand. Any source when blank.
FormThe capture came through the form with that id (from the form's address in Forms). Any form when blank.
Email domainThe captured address is at that domain — acme.com, typed with or without the @. Unlike the company link, a public mailbox such as gmail.com counts here, so a rule can route consumer sign-ups to one rep.
TagThe capture carries the tag, or the contact already has it. Case does not matter.

A rule with every condition blank matches everything, which is how a catch-all is written — put it last. The target is a team member, picked from the workspace roster by name, or Round robin, the next member of the pool in turn.

A rule naming a member who has since left the workspace is skipped, as is a round-robin rule while the pool is empty; the next rule down is tried. Use the arrows to reorder, and the row menu to delete. A workspace keeps at most 50 rules.

Rules run for every capture door on every site, including a lead that is converted without an owner picked, and only on a contact that has no owner yet. To reassign a contact that already has one, use an automation — the Assign the contact an owner step, which can also rotate through the pool.

Round robin​

The members handed contacts in turn by a round-robin rule, or by an automation set to round robin. Tick the members to include; the order they were ticked is the rotation order, shown beneath the list with who is next up.

Each new record goes to the member after the one who got the last record, wrapping round to the first. The pointer is moved by the server in the same write that assigns the owner, so two contacts captured at the same moment go to two different people, and editing the pool — adding, removing or reordering a member — never skips or repeats anybody: the next record goes to whoever follows the last recipient in the pool as it now stands. A member who leaves the workspace is skipped. A pool can hold up to 50 members.

Email templates​

The Email templates card lists every template and snippet you can use in Send email — the team's shared ones and your own personal ones — with its kind and who it is for. New template opens a drawer for the name, the kind, who it is for, the subject and the message; a row's menu edits or deletes it. A template written under a site is that site's; one written from the organization's own CRM is the whole workspace's, and every site lists it. Merge fields, the preview, and what shared and personal mean are on Email templates & snippets.

Email capture​

The Email capture card holds the workspace's one capture address, with Copy and Rotate address. The address looks like crm+…@in.aglyn.com. A message forwarded to it, or sent with it in BCC, is filed on the timeline of the contact or lead it was with, so a reply that reached your own mailbox lands on the record too. How a message is matched, what is kept and what is dropped is described under Captured email.

The address is the workspace's, not a site's: the card reads the same under every site and at the organization level, and the record's own site decides which timeline the message lands on. It is minted the first time somebody opens the card or the Send email dialog, and everybody who can open the CRM can copy it.

Rotate address replaces it, behind a confirmation, and takes the Change CRM settings permission. The moment the new address is written the old one goes quiet: mail sent to it afterwards is dropped without a trace, so a mailbox rule or a saved shortcut that carried the old address has to be updated. Rotate when the address has leaked outside the team — anybody who holds it can file mail on your records, though only mail from or to somebody already in the CRM is ever filed.

Your sending addresses​

Directly under Email capture, Your sending addresses lists the addresses you send from besides the one you sign in with, such as a Gmail Send mail as alias on an outbound domain. Emails you send from these addresses and BCC to your capture address are filed under the person you wrote to.

Without the list, a message from an address the workspace does not know is yours reads as a stranger writing in. The capture files it under the alias itself, as Received, or drops it when the alias is on no record, and the person you wrote to gets nothing on their timeline.

  • Add an address and a verification email is sent to it. The row reads Verification email sent, and Resend sends another.
  • Open the link in that email while signed in as yourself. The row then reads Verified, and from then on mail from that address is filed as yours: Sent, on the record of the person in To, with your name on the entry.
  • An address that is not verified changes nothing. A link opened while signed in as anyone else confirms nothing, and a link stops working after 24 hours or once its address is removed.
  • Connecting a Google mailbox in Sequences verifies any address on your list that Gmail already lists as one the account can send as — Gmail has confirmed it, so no email is needed. An address you have not added is never added for you.
  • Remove takes an address off the list. Removing a verified address asks first, and adding it again sends a new verification email.

Each member keeps their own list in each workspace, and nobody else can see or change it. It reads the same under every site and at the organization level. The address you sign in with already counts, so it is never listed. You can keep up to five addresses. Leaving the workspace, or erasing your account, removes your list.

An address that two members have both verified, such as a shared mailbox, is treated as the team's: mail from it is filed as Sent on the recipient's record, without a name on the entry.

Recipes​

At the organization level only — …/{organization}/crm/settings — the Settings section ends with a Recipes card: the four automation recipes, each with the sites that already carry it and an Install button. Automation is a site feature, and the site's own Actions page opens a recipe in the editor for you to change and save; this card is for the organization that runs several sites and wants the same automation on more than one of them without building it on each.

Install opens a drawer: pick the site, and for Tag by form one of that site's live forms, then confirm. The action the recipe builds is written into that site's Automation → Actions exactly as the recipe defines it — enabled, with the trigger, conditions and steps the recipes table describes — and stamped with the recipe it came from. The card then links to the site's Actions page, where the action can be edited like any other. Installing needs the same Manage data permission the organization's CRM needs, and the plan that carries the actions builder; on a plan without it the buttons are disabled and say so.

Each recipe lists the sites it is installed on, read from that stamp, and links each into the site's Actions page. A site that carries actions saved before the stamp existed is listed as may already have it: those actions could have started from the recipe, and the card will not call the site clear. Installing the same recipe on a site that already carries it is refused — Already installed on this site — rather than installed twice; delete the site's copy from its Actions page first if you want a fresh one.