Skip to content
Intellia Overview
Modules

Modules

A module is a registry entry that packages one or more of your existing app sites and/or workflows into a single, named product — { slug, name, description, version, visibility, category, tags } plus a set of roots.

Modules are authored by Hutly and browsed by every organization in a shared catalogue. Think of a module as the definition of a product; a later release will let an organization bring a module into its own workspace.

Roots

A root points at a resource that already exists in the authoring organization — a module doesn’t create anything new, it names and describes resources that are already built:

  • app_site — an existing app site, by id.
  • workflow — an existing workflow, by id.

An app_site root lists the pages it ships. A module can also add pages to a site one of its dependencies owns; see pages from a module’s dependencies.

Every root carries its own human-readable description — required, not optional. That description is what a browsing organization reads in the catalogue, so a module can’t be registered with an undescribed root.

Authored by Hutly, for now

Registering a module is currently restricted to Hutly’s internal authoring organization — a module’s roots must reference resources that live in that same org. This keeps the registry’s contents Hutly-curated while the rest of the system is Hutly-curated on the authoring side; bringing a module into your own organization — activation — is described below.

First-party modules and naming

Names starting with intellia are reserved for Intellia’s own, first-party modules. A first-party module has a slug starting with intellia-, is public, and declares a family in module.yaml; every workflow, schedule and webhook it ships is named intellia-<family>-… and every table intellia_<family>_…. An intellia- slug requires visibility: public and a family; a public module with any other slug is not first-party.

Every other module, public or private, names its objects after its own slug, such as acme-crm-sync and acme_crm_lead for a module acme-crm. intellia modules check reports an object outside that prefix as an error, and registration returns it as a warning. An object of such a module whose name starts with intellia is refused.

Naming something “Intellia …” without giving it a slug is fine: the platform derives a slug with its kind in front, such as agent-intellia-helper. The CLI reference lists the error codes registration and deploy return.

Activation

Activation clones a module’s resources into a consumer org. It runs as a stepped activation session, not a single call, because a module can carry secrets or integration references the consumer org hasn’t configured yet:

preview → holes → configure → accepted → deploying → done | failed
  • preview — the session is created; it snapshots the module and returns a summary plus any unresolved holes.
  • holes — unresolved secrets or integrations the module’s resources depend on. A session can’t be accepted while holes remain; resolve them (vault items / integrations) in the consumer org, then recompute.
  • configure — set the app_site slug (a module with no site of its own, whether workflow-only or one that only adds pages to a dependency’s site, has none) and any params.
  • accepted — a strict gate: accepting fails if any holes are still unresolved.
  • deploying — the accepted session’s resources are cloned into the org asynchronously.
  • done / failed — the terminal states.

A session has one of two snapshot origins:

  • registry — the session snapshots the module exactly as currently registered in the catalogue. This is the standard path: activating a module by its catalogue id.
  • uploaded — the session snapshots a bundle supplied by the caller instead of the registry — the shape intellia modules project emits, typically after Sammy has edited the projected tree. Uploaded origin currently supports workflows and agents only.

Drive a session step by step with intellia modules activation ..., or run the whole thing in one shot with intellia modules activate <target> (<target> is a registry module id, or a directory for uploaded origin). See the CLI reference and API reference for the full command/endpoint set.

Once activated, an org can hide or unhide the module without deactivating it — useful for temporarily removing it from view without losing its resource mappings.

Activating again

Activating a module the organisation already has brings it up to the catalogue’s current version. An app whose content changed gets a new version on the same page, and the page keeps the title and navigation setting the organisation gave it. An app whose content did not change is left alone. A page the module no longer ships is removed, and the activation reports how many; the app that page served, with its versions, stays in the organisation’s artifacts, where you can delete it. A page the organisation removed itself is not put back; the activation reports it as a warning. A site the module no longer ships stays in place, with its address and settings but none of the module’s pages, and the activation tells you once — remove it yourself if you no longer need it.

Two authoring channels

A module can be authored two ways, over one shared engine:

  • Interactively (Sammy). Sammy builds the workflows, agents, tables, and apps in the authoring org, then registers the module with intellia modules define — no files, no git; the registry references the live resources.
  • Code / CI (curated modules). A module is committed as a projected YAML tree under modules/<slug>/ in the repo (ids stripped, resources linked by !ref), and a CI action deploys it into the authoring org and upserts the registry entry with intellia modules deploy. This is the channel for curated, version-controlled modules; the YAML tree is the CI transport, not a per-module requirement.

Projecting a module

A registered module can be projected to a portable YAML package on disk — useful for review, diffing, or committing under modules/ — via intellia modules project. Deploying a projected tree back into the authoring org (and re-registering it) is intellia modules deploy, the code/CI channel above. Bringing a module into a customer organization is activation, described below.

Browsing the catalogue

Any organization can list the modules in the registry:

intellia modules list

This returns each module’s slug, name, description, version, visibility, category, and tags. See the CLI reference for the full command set, including how a module is registered.