Build a workflow for Inquiry Received

Use this recipe when you want every incoming inbound inquiry (form, landing-page submission, voice transcript, or imported lead) to run the same handoff: log it, tag it, alert an owner, and optionally draft a reply.

Before you start

• You need the workflows.create and workflows.publish permissions (owner / admin roles by default).
• One Inbound inquiry record must already exist in your org — that is the entity the workflow triggers on. Visit Inquiries to confirm.
• See Inquiries vs leads vs opportunities if you are not yet sure which lifecycle stage you are working with.

1. Pick the trigger

1. From Workflows click Create workflow.
2. In the Trigger dropdown choose Inquiry received (inbound.inquiry.received).
3. Fill in:
   • Machine name — lowercase, used internally (e.g. inquiry-triage).
   • Display name — what operators will see (e.g. "Inquiry triage").
   • Description — a one-liner. The publish review dialog shows it.
4. Click Create. The Builder opens for the new draft.

Trigger filters

Click the trigger node, then Configure, to narrow the firing set:

Leave a filter blank to match every value.

2. Add the first action

Click Add on the right-side panel (or the + after the trigger node) and pick one of these — they each match a different operator intent:

a. Log triage to the timeline — Append timeline event

The simplest start. Writes an immutable row to the inquiry's timeline so the audit trail records that triage fired. No customer-visible effect.

• Entity ref — type inquiry, idPath trigger.inquiry.id.
• Event type — inquiry.triage_started (free text).
• Summary template — e.g. Triage queued for {{contact.displayName}}.

b. Tag the inquiry — Add tag

Use this to bucket triage queues. Useful when you want a downstream view to filter on "needs reply", "international", "out of scope", etc.

• Entity — inquiry, idPath trigger.inquiry.id.
• Tag — pick a tag from this org (you must create it first under Tags).

c. Alert an owner — Send Vertiqa notification

Pushes a governed in-app / email notification to the inquiry owner.

• Recipients — OrgMember with idPath trigger.inquiry.contactId is rarely what you want; for owner alerts add a downstream Stage-gate Automove first, or use a static role recipient.
• Template — workflow.inquiry_received (or a custom template key set up under Notifications).
• Channels — usually Email + InApp.
• Notification class — Operational.
• Preference / Channel policy — leave both as respect_preferences / allow_configured unless you have a reason to override.

d. Draft a reply for human review — Draft customer reply

Drafts an email back to the original contact and puts it in the operator's review queue. The customer never sees it until a person approves.

• Entity — contact, idPath trigger.inquiry.contactId.
• Template — inquiry_acknowledgement.
• Draft channel — Email.
• Reviewer role — OrgRole / manager.

e. Hand off to the Draft Assist agent — Start Agent Library run

Runs the draft_assist AI agent against the inquiry. Output lands as an artifact in the Agent Library queue for operator review.

• Agent type — draft_assist (the only Agent Library agent eligible for inbound_inquiry).
• Entity ref — type inbound_inquiry, idPath trigger.inquiry.id.
• Requester — workflow_actor.
• Failure behavior — stop_workflow while you are first testing; switch to notify_owner once trusted.

3. (Optional) Branch on status

If you want the workflow to behave differently for, say, "voice" inquiries vs "form" inquiries:

1. Click Add → Condition after the trigger.
2. Context path — entity.sourceChannel.
3. Operator — equals.
4. Value — voice (or whatever channel you care about).
5. Add downstream actions on the yes branch; add a sibling tree on the no branch.

The publish review dialog reports the branch count, so a healthy "branch then merge" workflow shows e.g. 2 branches.

4. Validate

Click Validate workflow in the top bar. Autosave runs and the right-side panel reports:

• Saved with warnings — green, you can publish. Warnings (like "Draft customer reply requires human review before any customer-facing output") are informational.
• Errors — red. Each error has a path ($.nodes[<id>].config.<field>) pointing at the node and field to fix.

Common errors and what they mean:

5. Publish

Click Publish workflow. The review dialog shows:

• Trigger — what fires the workflow.
• Yes path / No path — branches you defined.
• Human review gates / Customer-facing output / Agent launches / Child workflow starts / Stage-gate decisions — buckets of nodes Vertiqa flags as customer-impacting.
• External messages stay manual-review only — confirmation that nothing autonomously emails a customer.
• Immutable workflow version — publishing creates a frozen workflow_versions row. New runs use the new version; existing runs keep the version they started on.

Click Confirm publish workflow. The page swaps to Version version-<uuid> and the workflow is now armed.

6. Verify it fires

1. Open Inquiries and submit a test inquiry from the Portal or trigger one via your live form.
2. Wait a few seconds, then open the workflow's Runs tab.
3. You should see a new execution row with status completed, waiting, or failed. Click Open to see the node timeline.

If nothing shows up:

• Confirm the workflow is published and active in the list.
• Check the inquiry's sourceChannel matches any filter you set.
• Make sure the inquiry actually went through the POST /api/v1/crm/inbound-inquiries path — handcrafted DB rows don't emit the outbox event the runtime listens for.

Related

• Workflows
• Inquiries vs leads vs opportunities
• Agent Library overview