Manifestly

View saved version →

---
name: build-edit-workflows
description: Create and edit reusable Manifestly workflow templates, including sections, steps, instructions, data fields, subtasks, ordering, and due-date rules. Use for designing a repeatable process, changing future runs, or copying a template. Excludes starting runs, completing run steps, and changing individual run assignments or deadlines.
---

# Build and edit workflows

A workflow is the reusable template. A run is one execution with its own copied steps. Use this skill to create or change the template; use run operations for work in a specific execution.

Follow the user's explicit scope and preferences over this skill's defaults. When the user asks for an outline or advice, provide that without creating records. When they request creation or a clear supported edit, carry it out without adding a routine approval step.

## Identify the target and scope

Use the account established by the user and resolve the department with `list_departments` when needed. Discover existing templates with `list_workflows` and inspect the chosen one with `get_workflow`; fetch its steps with `list_workflow_steps` using `mode: "hierarchy"`. The default step-list mode omits steps inside sections. For a complete structural inspection, follow all pages and omit `type` and `parent_step_id` filters, which override the mode and can narrow the results. Ask only when the account, target, or requested outcome is materially ambiguous.

"Add a step to this checklist" can mean changing a template or changing an open run. Resolve that distinction before writing when context does not establish it. **Template edits affect future runs; existing runs do not automatically change.** The MCP tools do not perform the app's explicit propagation action. Explain this when it affects the user's goal.

Use workflow and workflow-step IDs returned by template tools. Never substitute IDs from run responses. Tool names below refer to operations on the connected Manifestly MCP server; use the current schemas. Consult `docs` for unfamiliar operations or errors instead of guessing parameters.

## Create a template

Turn the user's process into an ordered outline with clear task titles, sections where useful, and only the requested or clearly supported data fields, subtasks, assignments, and timing. Resolve missing business decisions that would change execution; do not invent mandatory approvals or deadlines.

Prefer `create_workflow` for a new template from an outline. Put each section's steps inside its `steps` list; use top-level steps only for ungrouped work. The outline supports standard and stop-task steps, subtasks, due offsets, and one field per step.

After creation, use `list_workflow_steps` with `mode: "hierarchy"` and follow all pages to obtain the created step IDs and verify the full structure, including steps inside sections. Add further fields with `create_step_data_setting` and additional instructions with `create_step_content_block` as needed. Hierarchy responses may repeat a step at the top level and under a section; deduplicate by ID before counting or modifying steps.

Do not start a run merely to finish creating its template unless the user also requests a run.

## Edit an existing template

Read the relevant existing structure and apply a partial update that preserves unrelated settings:

| Requested change | Operation |
| --- | --- |
| Workflow name or description | `update_workflow` |
| Add a section or step | `create_workflow_step` |
| Step title, parent section, supported kind, subtasks, or due rule | `update_workflow_step` |
| Remove a section or step | `delete_workflow_step` |
| Step instructions or media | `create_step_content_block` / `update_step_content_block` / `delete_step_content_block` |
| Collected field definitions | `create_step_data_setting` / `update_step_data_setting` / `delete_step_data_setting` |
| Step order or movement across sections | `reorder_workflow_steps` |
| Holiday calendar attached to the workflow | `set_workflow_business_calendar` |
| Landing rule for dates that fall on a non-business day | `set_workflow_business_day_rule` |

On a version-controlled workflow, `update_workflow` saves the description into the published snapshot and the next promote silently overwrites it from the draft; the title is unaffected. Direct the user to edit the draft when the description must stick.

For a new step inside a section, pass its `parent_step_id`. In updates, omitting this key preserves the parent, while null moves the step to the top level. Sections cannot be nested. Updating a subtask list replaces the list, so include existing subtasks that should remain.

Before reordering, fetch the complete active hierarchy with `list_workflow_steps` using `mode: "hierarchy"`, follow all pages, and include every active nonblank step exactly once. Keep each section followed contiguously by its children. Do not accidentally include duplicate IDs from nested and top-level representations.

Template due dates are relative rules with a basis, offset, and units. Day offsets default to business-day counting; set `late_at_offset_units_mode` to `regular` when calendar days are intended. A date-field basis is configured in the editor, not these step-edit tools. Two workflow-level settings shape where computed dates land: `set_workflow_business_calendar` attaches a holiday calendar (found with `list_business_calendars`) so its dates count as non-business days, and `set_workflow_business_day_rule` moves a date that lands on a non-business day to the next or previous business day. Both need their account feature, and both affect runs started afterward only. Use `docs` with `dates` for the full rules.

Inspect field definitions before editing their configuration. Changing `value_format` to a format that carries no configuration silently clears `value_format_config`, discarding a list's choices or a data-table binding; supply the intended compatible configuration and read it back. Unknown configuration keys are silently filtered, so a list sent under other key names is accepted and left empty.

## Advanced templates and copies

For a new advanced template or an explicitly requested copy, inspect `get_workflow_schema`; use `export_workflow` when copying an existing template. Set the intended title because the export always appends " - Exported" to it, and drop source-scoped references such as `business_calendar_id` unless the destination has that same calendar. Map account- and department-scoped references to the destination, including role IDs discovered with `list_roles`. Preserve internal relationships required by the schema rather than blindly copying source IDs.

Use `validate_workflow_import` before `import_workflow`. Correct validation errors before creation. Import creates a new workflow; it is not an in-place update. Read the result back before reporting success, and check for a partial creation before retrying an uncertain or failed import. Do not archive the original as automatic cleanup: `archive_workflow` closes every scheduled or started run of the workflow and deletes its scheduled runs, and `unarchive_workflow` restores neither. Prefer renaming it with `update_workflow` when work in flight still needs it, and say what archiving does before calling it.

Assignments, conditionals, and approval configuration are not editable through the current step-edit tools. For new templates, use the import route only when its current schema and validation support the requested feature. For unsupported in-place edits, provide the workflow's returned editor link and explain the remaining action. Do not replace an approval with a stop task or clone a workflow to imitate an in-place edit.

## Verify and finish

Read back the affected template and confirm the requested structure and settings, including field configuration and date-counting mode. When verifying the full structure after creation, import, or structural edits, use `list_workflow_steps` with `mode: "hierarchy"` and follow all pages so nested steps are included. Report what changed, its effect on future runs, the returned editor link, and any unfinished or unsupported portion.

Authoring can be blocked by department permissions, archival, shared-copy locks, or version control. Explain the returned reason; for version-controlled workflows, direct the user to edit the draft and publish through the app. Do not retry unchanged 403/404/409 responses or switch accounts to evade them. For uncertain writes, read back state before retrying and reuse the same idempotency key where supported.

Remove steps, fields, or instruction blocks only within the user's requested scope. `delete_workflow_step` deactivates rather than erases, so runs in flight keep their copy; deleting a section deactivates every step inside it, so inspect it in hierarchy mode first. `delete_step_data_setting` and `delete_step_content_block` are hard deletes that cannot be recovered. Clarify the affected scope when the user's intent is unclear, rather than assuming permission to remove related content.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: manage-runs
description: Start and manage Manifestly runs and their assignments. Use for finding assigned work, collecting step data, completing or skipping tasks, reassigning tasks, and changing run or task deadlines. Applies to executions of existing workflows, not creating or editing reusable workflow templates.
---

# Manage runs

A workflow is a reusable template. A run is one execution of it, with its own run steps, assignments, field values, and dates. Use this skill for run work across any connected customer's workflows.

Follow the user's explicit scope and preferences over this skill's defaults. A request to inspect work does not authorize changing it. A clear request to perform an available action supplies authorization for that action; do not add a routine confirmation step.

## Establish context

- Use the connected account selected by the user or established in the conversation. If several accounts could satisfy a write and the intended one is unclear, ask which account. Discover IDs from tools, not sample data or remembered IDs from another account.
- Resolve runs with `list_runs` or `get_run`, retaining the returned run ID across follow-ups. A workflow ID, workflow-step ID, run ID, and run-step ID are different identifiers. Run-step IDs come from run responses or assignments.
- Resolve references such as "that task" from the active run and previous results. Ask when several records match; report a missing record without substituting one. Follow pagination when needed to establish a match or complete list.
- Tool names here refer to operations on the connected Manifestly MCP server. Follow the current tool schema. Use `docs` for unfamiliar behavior; its index identifies recipes and error explanations.

## Start a run and find work

Use `start_run_by_workflow_name` for a named workflow, or discover a workflow and use `create_run` with its ID. Resolve an ambiguous workflow or department before creation. Create the requested run once, retain its returned ID, and report preparation status if its steps are not yet ready. Do not start a run merely because the user asks to see workflows.

Use `list_my_assignments` for the authenticated user's assigned tasks. Narrow with its filters rather than paging and filtering client-side: `state: "overdue"` for overdue work, `due_after` and `due_before` (ISO 8601) for a date window such as "due this week", `kind: "approval"` for pending decisions, `search` for a title match, and `sort` (`due_asc` default, undated tasks last). By default only actionable steps are listed; pass `include_locked: "true"` to also see steps locked behind a stop task or approval, and `include_completed: "true"` to see finished ones. For "in this run," match returned assignments against the active run ID; a title search alone does not establish identity. For the next assigned task, use incomplete actionable assignments in due-date order, with undated tasks last. Respect a different priority requested by the user. Do not treat every step in a run as assigned to the user.

Use `get_my_status` for a broad workload overview. It is a dashboard, not an inventory: each list is a sample of at most 10 rows, and the real totals are in `counts`. Report numbers from `counts`, never from an array's length, and switch to `list_my_assignments` or `list_runs` to work through everything behind a count.

## Complete work and collect data

Inspect the target step with `get_run_step` when its type, prerequisites, or state are unknown. Section headers group steps. Calling `complete_run_step` on a header can also complete its child tasks, so skip headers when resolving "the first step" or "the next step." Do not bypass locked steps or mark prerequisites completed merely to unlock the target.

- **Data collection:** Call `get_fields` to discover field IDs, required values, and allowed options. Ask for missing required values without inventing them. Save supplied values using `set_fields`, or `update_field` for an isolated field update. Check every field result: a successful batch response may contain individual errors. Filling all required data auto-completes eligible steps; do not follow it with a redundant `complete_run_step`. Verify returned completion state or fetch the step if necessary.
- **Subtasks:** A step with `subtasks_required: true` cannot be completed until every subtask is done. Complete each one with `complete_subtask`, passing the run-step ID as `step_id` and the subtask ID from the step's `subtasks` array, and only when the user's instruction or supplied evidence supports marking that work done. `uncomplete_subtask` reverses one. Subtask changes never complete the parent step.
- **Ordinary tasks:** When required data and subtasks are satisfied, use `complete_run_step` with `include: ["next_steps", "progress"]`.
- **Approvals:** Use `approve_run_step` or `reject_run_step` only for a requested decision, never `complete_run_step`. Before deciding, fetch each step in `reviewed_run_step_ids` with `get_run_step` and inspect its data and comments. Both decisions require a non-blank comment. Check `can_decide` for either decision and `can_approve` for approval; explain blockers. A user who completed any reviewed step cannot approve or reject its approval.
- **Rejection scope:** Omitting `rejected_run_step_ids` from `reject_run_step` reopens every completed reviewed step. Choose the scope deliberately: for targeted rework, pass only the relevant IDs from `reviewed_run_step_ids`. Ask when the requested scope is unclear instead of defaulting to reopening everything. Rejection keeps downstream work gated by the approval locked; only approval releases that gate. Report which reviewed steps were reopened.
- **Retraction:** Use `retract_run_step` only when the user requests withdrawing an earlier approval and `can_retract` is true. It requires a non-blank comment explaining the reason. Retraction reopens the approval for a new decision and relocks downstream steps that the approval had unlocked; it does not record a rejection. Report those effects.
- **Skipping:** Use `skip_run_step` when the user asks to skip. Report it as skipped, even if the progress percentage increases. Skipping a stop task does not release its gate: unskip it, then complete it.
- **Reversing:** `uncomplete_run_step` reopens a completed step and `unskip_run_step` a skipped one; they are the same operation. Only `uncomplete_run_step` accepts `clear_data: true`, which also wipes the step's collected values. Without it the values survive and the step auto-completes again as soon as the last required field is refilled.
- **Comments:** `add_comment` posts a note on a run step and `list_run_step_comments` reads them. Comments never change step state.

Step-collected values and run-level fields are separate systems. For whole-run metadata, inspect the run's field definitions and use `set_run_field_values` with the appropriate workflow-field IDs. Consult `docs` for the `data` or `start-run-with-fields` page when needed.

## Change assignments and deadlines

For a task deadline, use `update_run_step_due_date`; for the run's own deadline, use `update_run`. Resolve relative dates in the user's established timezone. Ask only for date or target details that remain ambiguous, preserve an existing time when only the date changes, and send a timezone-qualified datetime.

Assign a person with `assign_run_step_by_email` or `assign_run_step_by_name` when appropriate. Direct `assign_run_step` uses a membership ID for the run's department, not a user ID. AI agents must be assigned by membership ID; their synthetic email addresses are not contact addresses. Resolve missing or multiple matches before writing.

Adding a step with `create_run_step` is supported only on ad-hoc runs, not runs started from templates. A template edit will not add the step to an existing run. Explain the applicable limitation rather than altering the template as a substitute.

## Report outcomes and failures

Confirm the actual task or run affected, saved values or deadline as relevant, returned progress, and a returned app link. Distinguish partial success from completion. Do not derive run progress from a workflow's step count.

Treat permission, not-found, and validation responses as reasons to resolve the specific issue, not to probe other accounts or retry unchanged requests. For an uncertain write outcome, read back the state before retrying; reuse the same idempotency key where supported.

Do not close a run as routine cleanup. `close_run` abandons a run; a run that finishes reaches `completed` on its own when its last step is resolved. Closing requires an explicit request, is admin-only, cannot be undone through these tools (only the app can reopen a closed run), and is refused for a run already in `completed`. After closing, every step write on that run returns a 422; reads still work. "Close this out" often means finish the remaining steps, so confirm which the user means before calling it.

Referenced files: 1 — file references are metadata, not package contents.