Curating modules

Discovery finds everything. Curation decides what your organisation actually uses, and what it calls things.

This is the difference between a tool that offers a hundred modules nobody imports into and one that offers the four you use, named the way your team names them.

Curation lives on the Modules tab of org settings, and — for the parts that deserve review and version control — in a configuration repository pushed with the sloose CLI. Both write the same thing.

Enabling modules, and the order

Enabling a module makes it available to import into. Anything not enabled is invisible to everybody using the wizard.

Order matters, and not cosmetically: it is the order records are created in within a row. A module that others point at must come first, because the link can only be written once the record exists. Accounts before contacts, contacts before deals.

Switching a module on or off, or reordering it, saves immediately — the tab sends the whole enabled set in order, so what you see is what the org has.

Your plan caps how many modules can be enabled. Exceeding it is refused with LIMIT_MODULES.

Keys and singular names

Two names, used in different places, and both worth choosing deliberately.

The key is how the module is referred to in mappings, projects and configuration files. Lower case, an identifier: accounts, contacts.

The singular is the name expressions use for a record written earlier in the row:

rec.Account.id

So Account as the singular means rec.Account. Choose the word your team would say. If you call them Clients, set the singular to Client and every formula anybody writes reads the way they already talk.

Both must be unique across the org — a clash is refused with KEY_CLASH rather than silently shadowing something.

The context name itself (rec) is configurable per org, under organisation settings.

Unique fields

Fields that identify exactly one record. Recording them buys two things:

• Validation warns when a job maps a unique field without a match rule, which is the setup that quietly creates duplicates.
• Auto-mapping is more careful with them. A guess that lands on a required, unique field is flagged for a person to check rather than applied, because a wrong value in a matching key is not recoverable by re-running.

If your accounts have an account number, this is where you say so.

Default match rules

A module can carry a default match rule — field, method and expression — which every new import starts from.

This is how you stop each person inventing their own answer to “what counts as the same account”. They can still change it for a particular file, but the default is the org’s considered answer rather than whatever the last person happened to pick.

Excluding fields

Fields nobody should map: internal identifiers, system timestamps, things maintained by a workflow.

Excluding them is not about security — they are still in the CRM and still visible there. It is about the mapping screen being usable. A module with 180 fields where 40 matter is much easier to work with once the other 140 are out of the way.

Exclusions can be set per module, or org-wide for system fields that appear on everything.

Seed mappings

Mappings applied to every new import where the field has no mapping yet.

Use them for the fields that are always the same: a lead source, a record owner, a fixed Imported by Sloose tag. It saves the same three mappings being made by hand every time, and it means they are made consistently.

A seed mapping is a starting point, not a lock — anybody can change it for their own import.

Colour and label

Cosmetic, and worth the thirty seconds. A colour per module makes a multi-module import readable at a glance in the grid and in the run report. The label is what people see everywhere.

A worked example

Two modules, in creation order, each with the fields that identify a record and a default match rule. Contacts seeds a mapping that points at the account written earlier in the same row:

modules.json

{
  "version": 1,
  "modules": [
    {
      "key": "accounts",
      "apiName": "Accounts",
      "label": "Accounts",
      "singular": "Account",
      "defaultEnabled": true,
      "uniqueFields": ["Account_Name"],
      "defaultDuplicateCheck": {
        "searchField": "Account_Name",
        "searchMethod": "equals",
        "expression": "row.Company"
      }
    },
    {
      "key": "contacts",
      "apiName": "Contacts",
      "label": "Contacts",
      "singular": "Contact",
      "defaultEnabled": true,
      "uniqueFields": ["Email"],
      "defaultDuplicateCheck": {
        "searchField": "Email",
        "searchMethod": "equals",
        "expression": "row.Email"
      },
      "seedMappings": {
        "Account_Name": { "mode": "expression", "transform": "rec.Account.id" }
      }
    }
  ],
  "systemExcludedFields": ["Created_Time", "Modified_Time"]
}

Doing this in a repository

Everything on this page lives in a configuration repository and is pushed with the sloose CLI, so the curation is reviewed, versioned and reproducible across orgs.

See Configuration as code.