How Actions work

Choose the right source for the answer#

Knowledge supplies the facts you publish or add to Reesponder: product descriptions, policies, opening hours and answering guidance. An Action supplies a controlled connection to information or an operation in another system. A shipping policy belongs in Knowledge; the current status of a particular customer’s order belongs in an authenticated lookup.

An Action does not create an API inside your business software. For a custom integration, you or your developer provide an endpoint that implements the task. Reesponder uses that fixed endpoint and the saved field definitions; the assistant cannot replace its destination, invent a credential or gain unrestricted access to your software.

Choose the source by asking whether the answer could change for a particular person between visits. Public opening hours can be explained from Knowledge. A customer's remaining appointment credit must come from the system that owns that balance.

Check the plan and website#

Business supports read Actions. Scale supports reads and visitor-confirmed writes. Core does not execute Actions. All plans use the same underlying Reesponder intelligence; these permissions control which connected operations are available.

Actions belong to an individual website in a workspace. An owner or admin manages their definitions and activity. An Action for one website is not automatically available to another, even when both share Knowledge. The workspace needs active access, and the website must remain active and installed.

A read configured on Business should therefore return a current fact, not secretly make a booking. If the intended task reserves a place or changes a record, design it as a confirmed write on Scale instead.

Available connection types#

A storefront widget installation is separate from access to order data. In particular, a Shopify theme snippet does not authorize Shopify Admin API lookups.

The connection type decides the contract. Native order adapters return their fixed summaries; custom HTTP uses your selected scalar mappings. Built-in requests retain a request in the workspace. These options cannot be interchanged merely by changing the task's name.

The customer’s path#

The customer asks for a task in ordinary language. Reesponder considers only enabled Actions whose current saved configuration has passed a test. It collects the defined inputs. Private operations use the widget’s email verification form. A read may execute when the required identity is already verified; a pending lookup shows the customer how to continue.

A write presents the exact collected details and a confirmation control. The customer can cancel instead. Your team does not need to approve every visitor operation individually, but your endpoint must enforce its own business rules. A successful result appears in the conversation with only the permitted result fields.

Action availability is checked again when execution begins. A proposal collected before a plan or configuration change does not carry permission forward by itself. This protects the operation from using a definition that your team has since withdrawn.

Start with one narrow task#

Begin with a read such as checking an order or availability. Confirm the destination can authenticate Reesponder and restrict private records to the verified customer. Define a small set of required inputs and useful outputs. Save, run a real test, review the returned data, then enable it.

Review Actions → Activity & requests after the first customer run. Expand into writes only when you have explicit validation, idempotency and a clear recovery path for uncertain outcomes. The Actions overview shows the experience; these guides document the integration contract.

Keep a written example question and its expected result for each task. Use that example again after configuration edits so your team can distinguish a routing regression from a destination failure.

Worked example: delivery answer versus order lookup#

A visitor asks, “How long does delivery take?” Reesponder can explain the store's published delivery policy from Knowledge. The same visitor then asks, “Has ORDER-1042 left the warehouse?” That question concerns a particular record. The order lookup collects the reference and verifies the buyer's email before the provider returns the current dispatch status.

Build these as two deliberate sources. Put normal timeframes, exceptions and contact instructions in Knowledge. Configure a read Action for an owned order. Its description should say that it checks current order status, not that it changes delivery arrangements. Map the authorized reference and status; keep internal fulfillment notes outside the customer result.

If the buyer subsequently wants a different delivery date, the read cannot perform that change. Offer a separately configured write that records a request or updates an eligible order, according to your endpoint's actual behavior. Its confirmation must describe the details the customer is submitting. A result of “Request received” is suitable for a request queue; “Delivery changed” is appropriate only when the owning system has completed the change.

Acceptance criteria for your first Action#

Before enabling, demonstrate an owned record, a different-owner record, a missing record and an unavailable destination. Record the expected customer outcome for each one. Run the live widget path with an email you control so you also test the verification dependency. A successful administrator test alone does not exercise code delivery or customer confirmation.

Check the result against the actual provider record and ensure the request appears under the correct website in Activity & requests. Decide who will inspect failed or uncertain outcomes and how that person will correlate the run reference with provider records. Enable only after those responsibilities are clear.

Turn a broad request into a maintainable task#

Start with the business verb, the record and the permitted result. “Check the status of an owned order” has a clear scope. “Help with everything in our store” does not: it mixes public explanation, private lookup and changes with different permissions. Split tasks when their identity rules, inputs or consequences differ.

A useful specification contains a representative question, the required input keys, the system of record, the identity check and the success statement. It also defines a normal negative outcome. For example, an unavailable appointment can be returned as a factual customer-safe result rather than an unexplained integration error.

Avoid several Actions with indistinguishable names and descriptions. The assistant uses these descriptions to select an appropriate operation; a broad overlap makes the choice harder to evaluate. Explain the condition that separates them, such as order status versus a return request. Keep the description focused on when and why to use the task, without putting secrets or unrestricted commands in it.

For the first rollout, choose a frequent read with a small result. That gives your team a manageable baseline for field collection, ownership and provider reliability before adding operations that change business state.

Assign the work after the result#

An Action is part of a service process, not the whole process. A booking request still needs the booking system to define whether a place was reserved. A built-in support request needs a person checking workspace activity. Choose the operational owner and the result's exact meaning before advertising the task to visitors.

Write down where that owner can find the destination record and the Reesponder run reference. Define when to escalate an unknown external write, who may reconcile it and what to tell the customer while the outcome is uncertain. A second proposal with a new reference is a new operation; it should not be your default response to a lost reply.

Review a small set of early customer runs. Look for missing inputs, ambiguous names, unsuitable result labels and repeated normal failures. Improve the narrow definition and destination contract, then save and retest the new revision. Editing does not silently retain approval from a previous test.

Keep long-running business records in the system that owns the process. Conversation-linked Action content follows conversation retention. A successful chat submission is not a permanent replacement for your order, returns or support ledger.