Knowledge BaseKnowledge Base

The Wazzi Workflows Connector

Build, release, assign, and activate owner workflows from your AI assistant — the write surface behind the Workflows platform. First-party, org-scoped, staff-only, requires no credentials.

October 8, 2026
7 min read

What this connector does

The Wazzi Workflows connector exposes the Workflows platform — owner-facing processes (annual reviews, onboarding packets, mid-season reporting, anything that recurs or needs an owner's signature or input) — as MCP tools. Agents and users with the right permissions can list, author, release, assign, and activate workflows across every property in the portfolio from Claude / ChatGPT / any MCP client.

This connector is internal to Wazzi. There's no external service to configure — no API key, no OAuth. It uses the Workflows platform's own database and your organization's existing property + owner data.

Who sees it

Staff only. The connector is permissions-gated:

  • workflows_view — read everything the user's collections allow
  • workflows_manage — author, release, assign, and activate workflows

Owners never see this connector. It cannot read owner documents or send anything to owners directly — those actions happen through the workflow itself (opening a cycle, which the owner then responds to in their portal).

The vocabulary

Three concepts carry through every tool:

  • Workflow — a template: a set of steps (uploads, signatures, Anvil web forms, manual tasks) plus a schedule (one-off, annual, every N years) and a recommendation rule (which properties it's for).
  • Property — the live rental unit a workflow is given to. A property can have 0 or many workflows assigned.
  • Cycle — one run of a workflow for one property in a specific period. Owners respond to cycles, not to workflows.

Workflow status moves not_assigned → assigned (set up but owner sees nothing) → active (owner has it, cycle open). Assign sets it up; start makes it live.

Setup — nothing to install

Step 1 — Enable the connector

  1. In the Wazzi Admin Center, go to Connectors
  2. Find Wazzi Workflows in the catalog
  3. Click Add — no secrets to paste; just confirm the enablement
  4. Click Test Connection — succeeds immediately since there's no external service to reach
  5. Click Save
Wazzi Admin Center Workflows connector edit page
No credentials needed — enable, Test Connection, Save.

Step 2 — Grant the right permissions

Workflows is double-gated: the connector grants the right to call the tool; the workflows_view / workflows_manage permissions decide what the user can see or change once the tool runs. Both are needed.

  1. In the Admin Center, go to Access Groups
  2. For each group that should use workflows from Claude, grant:
    • Workflows platform: workflows_view (read) and/or workflows_manage (change)
    • Wazzi Workflows connector: the specific MCP tools from the list below the group should use

Call get_status as a dry-run. It tells the user who they're connected as, which tools their permissions allow, which workflow collections they can see, whether Anvil is linked and in test or live mode, and what already exists. Any "refused" error from another tool usually traces back to something it reports.

Tool list — 17 tools

Discovery (read-only — grant to any workflows user)

  • get_status — identity + permissions + Anvil status. Call first when anything is refused.
  • list_workflows — workflows in your collections: name, schedule, draft/released state, step count, how many properties have it assigned vs active, open cycles.
  • get_workflow — one workflow in full: every step with its settings, prefill sources, recommendation rule, property counts.
  • list_categories — document categories (where uploads and finished Anvil docs are filed), with retention, owner-visibility, and sensitive-flag.
  • list_anvil_templates — the Anvil account's web forms and PDFs available to workflow steps, with their fields and prefill sources.
  • list_cycles — individual cycles: status, due date, progress, who it's waiting on. Filter by workflow, property, or status.

Property targeting (requires workflows_view)

  • find_properties — look up properties by name/address or by attributes (city, state, destination, area, community, group). Returns unit ids for assign/start.
  • property_workflows — every workflow for one property, with status (not_assigned / assigned / active / ignored) and whether the workflow's rule recommends it.
  • workflow_properties — the inverse: all properties for one workflow, with status and whether each is recommended by the rule. Filter by status or recommendation.

Authoring (requires workflows_manage)

  • upsert_workflow — create or edit a workflow and its steps. Edits produce an unreleased draft; the next release makes them live for new cycles.
  • upsert_category — create or edit a document category (retention, owner-visibility, sensitive flag).
  • create_anvil_web_form — build a web form from an Anvil PDF template for use in a workflow's web_form step.
  • publish_workflow — release pending edits so new cycles pick them up. Rarely needed explicitly: start_workflows releases automatically when nothing is running the old version. Use when properties are already active and you want new cycles to inherit your changes.

Targeting rule (requires workflows_manage)

  • set_recommendation — say who the workflow is for via a rule on property attributes. Scopes:
    • all — every property
    • none — no recommendation (manual assignment only)
    • matching — a when clause like {"city": ["Tucson"], "state": ["AZ"]} (AND across attributes, OR within one)
    Recommendation only suggests. Use assign_workflow to actually give it to properties.

Lifecycle (requires workflows_manage)

  • assign_workflow — give a workflow to specific properties (or take it away). Assigning sets it up (status ASSIGNED) — the owner sees nothing until it's started. Pass unit_ids explicitly, or recommended: true to assign to every property matching the recommendation rule. Supports dry_run.
  • start_workflows — make assigned workflows active. Opens each one's first cycle immediately. Three call shapes:
    • unit_id alone — every workflow assigned on that property
    • workflow alone — that workflow for every property it's assigned to
    • workflow + unit_id(s) — just those
    Auto-releases any pending edits (needs publish_workflow permission). dry_run supported.
  • start_cycle — open a cycle for one property + one specific period (e.g. to backfill last year's). Idempotent — won't duplicate an open cycle for that period. Also activates an assigned workflow.

Typical patterns

"Set up a new annual renewal workflow and roll it out"

  1. upsert_workflow — create the workflow with its steps
  2. set_recommendation — scope it to the right properties (e.g. all AZ)
  3. assign_workflow with recommended: true and dry_run: true — preview who it would reach
  4. assign_workflow again without dry_run — actually set up on those properties
  5. start_workflows with the workflow — make them active, opening the first cycle for each

"Backfill a workflow I missed last year"

  1. find_properties — get the unit_id
  2. start_cycle with that unit_id and the historical period — opens that one past cycle without affecting the live one

"Fix a wrong step on an active workflow"

  1. upsert_workflow — edit the step (saves as draft)
  2. Wait for current cycles to finish naturally, then publish_workflow — or if you want new cycles to pick it up immediately, release knowing already-running cycles keep their version

Troubleshooting

"Permission denied" when calling any tool

Call get_status — it tells you exactly which permissions you have and which collections you can see. If a specific tool is listed as unavailable, the user's access group doesn't have it; grant it in the Admin Center.

"Workflow has unresolved issues — cannot publish"

publish_workflow refuses when a step isn't set up well enough to be answered. The error message names each issue — a common one is an upload step without a category, or an Anvil step without a template. Fix the step via upsert_workflow and retry.

"Owner isn't seeing the workflow" even though it's assigned

Assigned ≠ active. The owner only sees workflows after the first cycle opens. Call start_workflows on the property to activate everything that's assigned, or start_cycle to open a specific period.

Anvil step says "no template"

Call get_status — it reports whether Anvil is connected and in test or live mode. If not connected, add the Anvil connector first. If connected but no templates visible, call list_anvil_templates to confirm what's in the Anvil account.

"Recommended" count doesn't match "assigned" count

Expected — they're separate. Recommendation is the rule's reach (how many properties the rule would match); assigned is how many properties the workflow has actually been given to. Use workflow_properties to see the full breakdown.

Related articles

Was this article helpful?