Skip to content

Projects

A real feature usually has several moving parts: a workflow or two, maybe a script, all wired to the same trigger or working on the same data. A project groups those parts together so you can see the whole feature in one place and manage it as a unit.

Projects are containers. Assigning something to a project does not change how it runs — it just organises related work.

A project currently groups workflows and scripts. Because a script is a workflow with a single code step, both show up as members of the project they belong to.

The project’s detail page lists its members in two sections — Workflows and Scripts — each showing the member’s name and whether it is enabled. The project also tracks member counts, so a project card can show, for example, “3 workflows · 1 script” at a glance.

Every project is either active or archived. The Projects page shows active projects first; archived ones are collected under a separate Archived heading so finished features stay out of the way without being deleted.

Archiving is reversible — change a project’s status back to active at any time from its settings.

Each project can carry an accent colour, shown as a coloured dot next to its name on the list and detail pages. Set it when you create the project or edit it later. The colour is optional; a project without one falls back to a neutral dot. Use it to tell related projects apart quickly.

  1. Open the Projects page

    Sign in to team.sprigr.com and click Projects in the sidebar, then click Create Project.

  2. Fill in the details

    • Name (required) — what the feature is, such as “Customer onboarding”.
    • Description (optional) — a short note on what the feature does.
    • Accent colour (optional) — a hex value like #cde66b for the project’s dot.
  3. Create it

    Click Create Project. You land on the new project’s detail page, ready to assign members to it.

A new project starts empty and active. The slug used to reference it is derived from the name and made unique within your organisation.

Members are assigned from the workflow or script side, not by adding them on the project page.

When you create a workflow, the create form has a Project field — pick a project there and the workflow appears under it. You can also change a workflow’s project later from its settings. The same applies to scripts.

Once assigned, the workflow or script shows up in the matching section of the project’s detail page, and it counts toward the project’s member totals.

From a project’s detail page you can:

  • Edit its name, description, and accent colour.
  • Archive it (or restore it to active) to move it in and out of the Archived section.
  • Delete it.

Deleting a project does not delete its members. The workflows and scripts assigned to it are detached and become unassigned — they keep running exactly as before. Only the grouping is removed.

Managing projects with an agent or over MCP

Section titled “Managing projects with an agent or over MCP”

Projects have full parity for agents and external tools connected over MCP:

  • create_project — create a container with a name, optional description, and optional colour.
  • list_projects — list the organisation’s projects with their member counts.
  • get_project — fetch one project with its members enumerated and a description of how those members relate (a shared trigger event, a shared agent, a data handoff through a Sprigr index, or a shared integration).
  • update_project — change a project’s name, description, colour, or status (active or archived).
  • delete_project — remove the container; members detach and become unassigned.

To put a workflow in a project through an agent, create or update the workflow with the project’s projectId.

  • Creating Workflows — The create form’s Project field assigns a workflow as you build it.
  • Scripts — Code-first automations that can also belong to a project.
  • Workflows Overview — How workflows, steps, gates, and triggers fit together.