DonnaJames

Build and operate chatbots with in-chat forms through DonnaJames, managing agents and growing the knowledge base. Agents keep bot answers grounded in current source material and collect structured responses mid-conversation.

1 trigger 23 actions API key available

DonnaJames website ↗ Platform Documentation ↗ Capability data verified 2026-08-01

On New Session fires when a visitor opens a chat on the selected chatbot

Agent reads the session meta block for what the visitor typed into the in-chat form, plus any verified identity data

Agent checks the captured fields are complete enough to act on rather than a form the visitor abandoned halfway

Agent looks the person up in the CRM to see whether this is a new contact or an existing account

Agent writes the submission into the CRM carrying the session UUID, so the transcript stays reachable from the record

Agent routes the qualified submissions to the owning rep alongside the questions the visitor actually asked

The rep decides which submissions warrant outreach and which are support questions wearing a lead form

What This Integration Enables

The distinguishing feature of DonnaJames is that the chatbot collects structured data, not just answers. An in-chat form runs inside the conversation and its submission lands in the session's meta block under the visitor key, with verified identity details filed under a separate key when identity verification with data saving is switched on. That means the useful output of a DonnaJames conversation is not only a transcript. It is a record with named fields you can validate, route and write to another system, sitting next to the exchange that produced it.

For a FlowRunner agent that changes what the connector is for. It is not primarily an answering endpoint, it is a capture surface. Get Session and List Sessions read the form data back out. List Session Messages returns the paired questions and responses with their citations and finish reasons, so the context around a submission is available at the same time. The knowledge base side exists to keep the bot's half of the exchange honest: Add Question And Answer pins the answers that must be exact, Add URL Source and Rescrape URL Sources keep pages current, and source tags scope a particular agent to a particular subset of material. Everything the bot says can be grounded, and everything the visitor says can be structured. The judgment about what to do with the pair is where a person comes in, which is the arrangement Orchestration as a Service is built around.

Without FlowRunner

Form and conversation live apart The visitor answers a form, then repeats themselves to the bot

Captured fields with no context A name and an email arrive with no record of what the person wanted

Everything routed the same way Support questions and buying signals land in the same undifferentiated list

With FlowRunner

Capture happens inside the conversation The bot asks for what it needs at the point the visitor is already talking

Submission and transcript stay joined The record carries the fields, the session UUID and the questions that surrounded them

Routing informed by the exchange The rep sees what the visitor asked before deciding whether it is theirs

Use Case Scenarios

A conversation that ends as a CRM record rather than a transcript

A visitor asks the bot about implementation timelines. Partway through, the in-chat form collects their name, company and a rough headcount. On New Session fires with the session record, and the meta block already carries what they typed. The agent validates the fields, calls List Session Messages to read what the person actually asked, and writes both into Attio: the structured fields as properties, the questions as a note. Nothing is retyped and nothing is inferred from a name and an email alone. The rep opening the record sees a person who asked three specific questions about timelines, which is a different prospect from a row that says only that someone filled in a form.

Answers that must be exact, kept exact

Pricing, refund windows and support hours are the answers a bot cannot be allowed to paraphrase. The agent maintains those as Q&A pairs with Add Question And Answer, each with a reference link attached so citations point somewhere useful when they are turned on. Everything else comes from crawled pages: Add URL Source queues them, List Data Sources confirms each one reached success rather than an error status, and a weekly flow calls Rescrape URL Sources so the marketing site and the bot do not drift apart. The result is a knowledge base with two tiers, one hand written and stable, one crawled and refreshed, and only the second tier ever changes on its own.

Acting on a claim only when the session actually verified it

A visitor says they are on the enterprise plan and asks the bot to confirm their renewal date. The session meta block is where the truth lives: with identity verification and data saving enabled, verified details appear under the auth data key, and when they are absent the visitor is simply an anonymous person making a claim. The agent branches on that. Verified sessions get the answer pulled from the billing record. Unverified sessions get a route to a person instead, with the transcript and the claim attached, because an automation that reveals account specifics to whoever typed the right company name is a data incident waiting for a slow afternoon. A support rep confirms identity the way the company already confirms identity, and the agent resumes.

Human-in-Loop Highlight

Delete Chatbot is the gate, and what makes it worse than it looks is where the form data lives.

DonnaJames stores an in-chat form submission inside the session record's meta block. There is no separate leads object, no export endpoint, no second home for it. Delete Chatbot permanently removes the chatbot together with its sessions, messages and training data, which means it destroys every form submission ever collected through that bot in the same call. And the operation that would tell you what you are about to lose is unhelpful here: List Sessions takes no pagination or filter parameters and returns the full set, so on a busy chatbot the only way to answer "how much captured data is in there" is to pull everything and count it downstream.

So a decommissioning flow does exactly that before it asks. It walks List Sessions, counts the sessions whose meta block carries a form submission, checks how many of those already exist as records in the CRM, and posts the difference: "Retiring the campaign chatbot. It holds 1,844 sessions, 612 of which carry an in-chat form submission. 47 of those 612 have no matching contact in the CRM and exist nowhere else. Export them first, or confirm deletion anyway?" A person answers. The same shape covers Delete Data Sources, which stops the bot answering from that material immediately, and Delete Message, which removes both halves of an exchange from a transcript that may be the only record of what a customer was told. The agent counts and reconciles. A person decides whether the thing being destroyed was the only copy.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

23 actions

Chatbots

List Chatbots Returns every chatbot on the account with its UUID, timestamps and meta block covering visibility, rate limiting and whether answers cite their sources. The UUID returned here identifies the chatbot in every other operation.
Get Chatbot Returns a single chatbot by UUID with its name, timestamps and meta block covering visibility, the rate limit and its message, and whether citations are shown. Used to confirm configuration before a workflow starts a conversation.
Create Chatbot Creates a chatbot and returns its UUID. Visibility controls who may reach it, and the rate limit is a pair of numbers meaning at most this many messages within this many seconds. Citations append the source of each answer when enabled.
Update Chatbot Changes a chatbot's name, visibility, rate limit or citation behaviour, modifying only the fields supplied. Both rate limit numbers must be supplied together because the API stores them as a single pair.
Delete Chatbot Permanently removes a chatbot together with its sessions, messages and training data. This cannot be undone, and because in-chat form submissions live inside the session records, it destroys captured data along with the bot.

Sessions and Form Data

Create Session Opens a new chat session against a chatbot and returns its UUID. A session is the container every message belongs to, so this comes first when a workflow drives the conversation from its own interface.
Get Session Returns a single session with its timestamps and its meta block. The meta block carries the in-chat form submission under the visitor key and identity verification data under the auth data key, which is how form responses are read back out of a conversation.
List Sessions Returns every session belonging to a chatbot with its UUID and timestamps. The endpoint takes no pagination or filter parameters and returns the full set, so a busy chatbot produces a large payload that is filtered downstream.

Messages

Send Message Sends a visitor question into an existing session and returns the agent's answer. The underlying endpoint streams plain text, so this action collects the full stream and returns it as a single string.
List Session Messages Returns the full message record of a session, each entry pairing the visitor's question with the agent's response plus its finish reason and timestamps. Citation and metadata fields come back as JSON encoded strings and are parsed before use.
Delete Message Removes a single message from a session so an incorrect exchange can be pruned from a transcript. This cannot be undone.

Agents

List Agents Returns the agents configured on a chatbot with type, prompt, description, enabled state, linked data sources, variables, tags, model and temperature. A chatbot may hold only one human escalation agent and one spam defense agent.
Create Agent Adds an agent to a chatbot. The type decides its role: user facing agents answer visitors, background agents label conversations, and the human escalation and pre-canned types handle handover and fixed replies. New agents are created disabled.
Update Agent Updates an agent's configuration and is how a newly created agent is switched on, since agents start disabled. Prompt, description, model, temperature, linked data sources, escalation settings, variables and tags can all be changed.
Delete Agent Permanently removes an agent from its chatbot. Conversations it already handled are unaffected, but it takes no part in new ones from that moment.

Knowledge Base

List Data Sources Returns the knowledge base sources of a chatbot with title, kind, indexing status, file name and size, token count and timestamps. Statuses beginning with error indicate an ingest failure, while success means the source is ready to answer from.
Add Question And Answer Adds a question and answer pair to the knowledge base, which is the most direct way to make the bot answer a known question exactly as written. A reference link can be attached so the answer cites its origin when citations are on.
Add URL Source Queues a web page for scraping into the knowledge base and returns the created source with its indexing status. Ingestion is asynchronous, so List Data Sources is polled until the status reaches success.
Rescrape URL Sources Re-crawls a set of URL sources so the chatbot answers from current page content. The response reports the outcome per source, so a partial failure returns a mixture of restarted entries and per item errors rather than failing everything.
Update Data Source Renames a knowledge base source so it is easier to identify in listings and in answer citations. The underlying content is unchanged.
Delete Data Sources Removes one or more knowledge base sources in a single call, so the bot stops answering from that material. This cannot be undone.

Source Tags

Create Source Tag Creates a colour coded tag and optionally attaches it to a set of knowledge base sources, so training material can be grouped and scoped to particular agents.
List Source Tags Returns the source tags defined on a chatbot with their colour and the data sources currently attached to each. Used to discover the tag vocabulary before scoping an agent to a subset of the knowledge base.

Triggers

1 triggers

Event Triggers

On New Session Fires when a visitor opens a new chat session on the selected chatbot, emitting the session record together with the data captured by any in-chat form under its meta block. DonnaJames publishes no webhook registration API, so this trigger polls the sessions endpoint rather than writing to your chatbot configuration. The first poll establishes a baseline without firing, so existing sessions are not replayed, and new sessions are emitted oldest first.

Frequently Asked Questions

What can FlowRunner do with DonnaJames?

FlowRunner agents can run List Chatbots, Get Chatbot, and Create Chatbot in DonnaJames, plus 20 more actions.

Does connecting DonnaJames to FlowRunner require OAuth?

No. DonnaJames connects to FlowRunner with an API key, no OAuth flow required.

Can DonnaJames trigger a FlowRunner workflow automatically?

Yes. DonnaJames supports 1 trigger that can start a FlowRunner workflow automatically.

Start building with DonnaJames

$100 in credits. No card required. Connect in minutes.

Start Building Free Talk to us