Wayfront

View saved version →

---
name: wayfront-form-setup
description: Choose, design, create, or improve Wayfront order, contact, intake, and onboarding forms and connect them to the right services. Use when deciding which form type to use, planning fields, reducing checkout friction, or configuring a customer information flow.
---

# Wayfront Form Setup

Design forms around when the information is needed. Do not put every question into one form.

## Choose the form type

- **Order form:** self-service signup or checkout. It lets clients choose services and can collect payment. Keep it short. It must contain an email field and at least one service-bearing field.
- **Contact form:** a general inquiry, quote, or support request that is not attached to an existing project. A submission creates a ticket. It must contain an email field and may redirect after submission.
- **Intake form:** information needed for one purchased service or project. Attach one intake form to the relevant service so checkout stays focused on conversion.
- **Onboarding form:** information that is reusable across the client relationship, such as brand details or account access. Attach it to the services that require it instead of asking for the same information on every project.

Use more than one form when information belongs at different moments. If the user's process is unclear, ask what starts the relationship, when payment happens, what changes per project, and what should be collected only once.

## Inspect before designing

Use `workspace-info` if form access is unavailable or the user is unsure which workspace is connected. Use `search-wayfront-docs` when the choice depends on current Wayfront behavior that is not present in the live form schema or records.

List existing services and forms first. Show an existing form before editing it, and inspect its attached services. Reuse or refine a suitable form instead of creating a duplicate. Use folders only when they make a larger form library easier to navigate; folders can contain only forms of their own type.

Use `form-read`, `service-read`, and `form-folder-read` for inspection. Changes use `form-write`, `service-write`, and `form-folder-write` respectively. A read tool cannot accept a write action.

Before writing, present the proposed form as an ordered field plan with each field's label, type, required state, purpose, and relevant services. Make fields required only when the workflow genuinely cannot continue without them. Use help text where the requested answer or acceptable format would otherwise be ambiguous.

For order-form service selection, use one of the service-bearing field types supported by the tool: `dropdown` or `optgroup` for a single choice, and `multiselect` or `checkgroup` for multiple choices. Reference verified service IDs. Payment processors must already be connected manually before their payment options can work.

## Create or update safely

Fields can be added, edited, reordered, and removed later through MCP. The important constraint is how updates work: form creation requires the complete initial field list, and an update that includes `fields` performs full field synchronization.

Immediately before a field update, show the form and construct the complete desired list. Include every retained field with its existing `id` and intended `sort_order`; omit `id` only for a new field. Translate the read response into the write schema rather than sending it back verbatim: map `services[].id` to `service_ids`, and map services whose `pivot.default` is true to `default_service_ids`. Include only fields accepted by the update schema.

Every existing field omitted from the list is deleted, and rules involving deleted fields are cleaned up. There is no MCP dry run or version restore. Present a concise before/after field diff and obtain confirmation before invoking the update.

Omit `fields` entirely when changing only form-level settings. Preserve service attachments, option values, default services, help text, required state, and rules unless the user asked to change them. If the form has any white-labeled service, all field updates are blocked.

Prefer separate calls for form-level changes and field synchronization so each result is easy to verify. Re-read the form after any update error before deciding whether to retry.

After creating an intake form, attach it with the service's `intake_form_id`. After creating an onboarding form, update each service's complete `onboarding_form_ids` list while preserving existing associations. Order forms connect services through the form's service-bearing fields. Contact forms do not attach to an order.

After a write, inspect the returned form and summarize its type, fields, service connections, and edit URL. If sharing, embedding, payment connection, or visual preview still requires the Wayfront interface, identify that as a separate manual step rather than claiming the form is fully launched.

When the user wants examples or an interface walkthrough, search the current Wayfront documentation, retrieve the relevant result with `get-wayfront-doc`, and share its canonical source URL.

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

View saved version →

---
name: wayfront-querying
description: Find, filter, sort, paginate, and summarize records in a connected Wayfront workspace. Use for reports, audits, record lookup, and questions spanning clients, orders, tickets, invoices, subscriptions, services, or forms; use the narrower setup skills for configuration changes.
---

# Wayfront Querying

Query only the part of the workspace needed for the user's question. Do not inventory every tool or fetch every record before starting.

## Query efficiently

Use `workspace-info` when the user asks which workspace or account is connected, or when unexpected permissions make the connection context relevant. Do not call it before every ordinary query.

Use the live schema for the chosen entity tool to confirm its current fields, actions, and workspace-specific status codes. Start with a filtered `list`, then use `show` only for records whose full detail matters.

For entities that support changes, queries use the separate `*-read` tool (for example, `order-read` or `service-read`). Those tools cannot write. Existing read-only tools such as `invoice-tool` and `subscription-tool` keep their names. Configuration changes use the corresponding `*-write` tool.

Most list actions accept:

- `filters`, such as `{"name":{"$contains":"Monitoring"}}` or `{"type":{"$eq":"intake"}}`;
- `sort`, such as `["created_at:desc"]`;
- `limit` and `page` for pagination.

Filter names are model-specific. Do not guess a field that is absent from the tool schema. Status filters use schema-defined numeric codes, not labels; the display labels can be customized by workspace.

Read the returned pagination object. Continue only while `current_page < last_page`; an empty page beyond `last_page` is a successful empty result, not an error. If the user asks for every matching record, paginate to completion. Otherwise state the time range, filter, or result limit used.

## Use the right identifier

Most entities use numeric IDs, but orders and tickets use their string `number`; invoice identifiers can also be strings. List first when the identifier is unknown and pass the exact identifier field named by the tool schema.

## Interpret access and errors

An empty result means no visible record matched the query. It does not prove that inaccessible records do not exist. If access is unexpectedly denied, call `workspace-info` and explain the connected workspace, staff role, relevant role-level capability, and any record-level scope that may still apply instead of repeatedly loosening filters.

When a filter or sort fails, compare it with the live schema and retry once with a supported field. Do not retry generic server errors in a loop. Preserve the original scope when correcting a query.

For configuration changes, load the relevant workflow skill before writing: `$wayfront-workspace-setup`, `$wayfront-service-setup`, or `$wayfront-form-setup`.

Use `search-wayfront-docs` for connection, permissions, product behavior, or interface instructions that are not answered by live workspace data. Retrieve a selected result with `get-wayfront-doc` when its full context is needed, and share its canonical source URL with the user.

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

View saved version →

---
name: wayfront-service-setup
description: Design, create, audit, or update Wayfront services, including pricing, recurring billing, renewal order behavior, request allowances, intake and onboarding forms, task templates, deadlines, assignments, and add-ons. Use when deciding how a sold service should create and renew delivery work.
---

# Wayfront Service Setup

A service is both a catalog item and a template for the orders created when it is purchased. Confirm how the work should repeat before changing its billing or renewal settings.

## Inspect the current setup

Use `workspace-info` if service access is unavailable or the user is unsure which workspace is connected. Use `search-wayfront-docs` when the decision depends on current Wayfront behavior that is not present in the live service schema or records.

List and show the relevant service before proposing a change. Also inspect intake and onboarding forms separately: service responses do not include every attached-form relationship, while form responses show their linked services. Check active subscriptions when changing a recurring service.

Use `service-read` for `list`, `show`, and `get_task_templates`; use `service-write` for `create`, `update`, and `sync_task_templates`. Form inspection uses `form-read`; existing subscription inspection uses `subscription-tool`.

Recommend variants only when an option changes price or quantity but keeps the same forms, tasks, renewal behavior, assignees, and reporting. Use separate services when those workflows differ. Variants are visible through MCP but cannot be created or updated there; hand variant configuration to the Wayfront interface.

## Choose billing and renewal behavior

The MCP exposes raw service codes. Interpret them for the user instead of presenting the codes alone:

- `recurring = 0`: one-time service.
- `recurring = 1`: recurring service without a trial or setup period.
- `recurring = 2`: trial or setup-fee period followed by recurring billing.
- `recurring = 3`: legacy limited-recurring-count mode. Preserve an existing service with this value unless the user explicitly wants to migrate it, and use the Wayfront interface for that decision; do not select it for a new MCP-created service.
- `r_period_t`: `D` days, `W` weeks, `M` months, or `Y` years; `r_period_l` is the number of those periods.

For a recurring service, choose exactly one `recurring_action`:

- `0` — **reopen the same order:** use for one continuing engagement, such as ongoing SEO for one website. A successful renewal returns the existing order to the work queue, resets its due date when configured, resets its existing tasks to incomplete, and syncs order-level staff from the current service. It keeps the existing order tasks and their assignees rather than importing the latest service task template. The conversation and delivery history stay on that order.
- `1` — **create new order(s):** use when each billing cycle is independent work, such as a new article or design project each month. Each cycle gets a separate order and its own intake and task state. `multi_order` is the number of orders created per purchased quantity and renewal cycle when greater than one.
- `2` — **service requests:** the subscription grants client-requested orders. `request_orders` is the per-period allowance: `0` disables requests and `127` represents unlimited. `max_active_requests` limits simultaneous unfinished requests, with `0` meaning no active limit. Use an active-at-a-time limit when “unlimited” should still protect team capacity.
- `3` — **no delivery action:** use for billing-only renewals such as hosting when no new or reopened work is required.

Explain the recommended option in plain language and obtain confirmation before writing it. For recurring services, `r_period_l` and `r_period_t` are required. A trial/setup service also requires its initial period and price settings.

## Consequential settings

- Changing `recurring_action` changes what future successful renewals do, including renewals on existing subscriptions that still reference the service. Review active subscriptions first.
- Changing catalog pricing or billing periods does not update the payment amount or schedule of an existing processor subscription. Existing subscriptions must be changed through subscription management; the MCP subscription tool is read-only.
- Supplying `employees`, `parent_services`, `onboarding_form_ids`, or metadata on update replaces that complete collection. Service reads do not currently return employee or add-on-parent assignments, so do not write `employees` or `parent_services` unless the user supplies or explicitly confirms the complete desired list. Reconstruct intake and onboarding associations from form responses, preserve every verified association that should remain, and re-read the related forms after writing. `intake_form_id` replaces the current intake-form association.
- `sync_task_templates` replaces the service's entire reusable checklist. Template edits apply to newly created orders; they do not rewrite tasks already copied onto existing orders. Reopening an existing recurring order resets that order's existing tasks rather than importing a newer template.
- Making a service public changes what clients can discover and buy. Changing add-on parents changes where it can be offered. A deadline affects due-date behavior once work can begin.

Before a consequential update, show a concise before/after summary covering price, billing interval, renewal behavior, verified forms, tasks, known assignments, visibility, and affected active subscriptions. Mark relationships the MCP cannot verify as unknown rather than implying the audit is complete. After writing, show the service and related forms again and separately identify anything that still requires the Wayfront interface.

For a user-facing product explanation or interface walkthrough, search the current Wayfront documentation, retrieve the relevant result with `get-wayfront-doc`, and share its canonical source URL.

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

View saved version →

---
name: wayfront-workspace-setup
description: Guide a Wayfront workspace owner from an empty or prebuilt workspace to a tested client ordering workflow. Use for new-workspace onboarding, launch readiness, or reviewing an incomplete setup across services, forms, branding, team access, payments, and delivery.
---

# Wayfront Workspace Setup

Help the owner reach one real outcome: a client can buy or be invoiced for the primary service, provide the right information, and create delivery work the team understands. Do not optimize for checking every feature box.

## Review before building

Call `workspace-info` first so the selected workspace, staff role, and role-level capabilities are explicit. If a necessary setup action is unavailable, explain the permission or manual handoff before designing around it.

Inspect current settings, services, and forms before asking what to build. Identify the primary or relevant services first, then inspect task templates only for those services; do not fetch every service checklist by default. Inspect team roles, pipelines, and integrations only when they matter to the intended workflow. If services or forms already exist, review and refine them rather than recreating or duplicating them.

Use the `*-read` tools for inspection and their `*-write` counterparts for approved changes, such as `settings-read` / `settings-write`. Team lookup remains `team-tool`; staff invitations and role changes remain `team-management-tool`.

Ask only for decisions the existing data cannot answer:

- what the business sells, its price, and whether delivery is one-time, recurring, or request-based;
- whether clients buy directly, request a quote, or receive a manual invoice;
- what information belongs at checkout, with each project, or once per client relationship;
- who owns each delivery step;
- whether sales or production stages, notifications, or automations solve a current need.

If the workspace is empty, start with one question about what they sell. If it is prebuilt, summarize the primary existing service instead of interviewing them from scratch.

Present the proposed primary package in plain language, not as a field dump:

- what is sold, for how much, and whether each renewal reopens work, creates new work, grants requests, or bills only;
- what the client provides at checkout;
- what is requested for each project through intake;
- what is requested once per client through onboarding;
- the delivery checklist and who owns it.

Ask: "Does this setup make sense, or would you like to make changes?" Do not create or update services, forms, or task templates until the user approves that package or gives the requested edits.

## Build the approved workflow

1. Configure the approved service behavior. Use `$wayfront-service-setup` for pricing, recurrence, renewal delivery, forms, and task-template consequences.
2. Configure the approved checkout, intake, and onboarding flow. Use `$wayfront-form-setup` for form choice and safe field updates.
3. Set business name, timezone, currency, contact link, brand colors, and public logo URLs.
4. Review staff roles and invite only the people needed for the workflow. Invitations can send email.
5. Add pipelines, automations, Slack notifications, or webhooks only when the user described a need for them.

Keep setup conversational: ask one or two decisions at a time and use the user's words for service names. If several services exist, settle the primary one first, then apply the agreed pattern to the rest only with permission.

## Finish with a real test

MCP can configure workspace branding, business information, services, forms, roles, pipelines, automations, Slack notification choices, and webhooks. It cannot connect Stripe, configure a custom domain or custom sending email domain, connect Slack, or switch the workspace to live mode.

Invoice data is read-only through MCP. If the approved sales path uses manual invoices, hand off invoice creation and sending to the Wayfront interface.

After the catalog and forms are approved, guide the owner through the remaining manual sequence: connect the payment processor, confirm branding, configure domain/email if needed, place a test order in test mode, inspect the resulting client/order/intake experience, and only then switch to live mode. Do not call the workspace launch-ready until that test has happened.

Use `search-wayfront-docs` when current product guidance or a matching interface walkthrough would help. Retrieve the selected result with `get-wayfront-doc`, base the recommendation on that current source, and share its canonical URL with the user.

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