Gathering information

Sometimes a workflow needs information that only a specific person holds: a manager's sign-off, a vendor reference number, a colleague's availability. The data-gathering step has Harriet contact that person directly, wait for their reply, and hand a clean summary to the next step.

How a data-gathering step runs

1. Harriet finds the contact channel. It looks up the person's Slack DM channel or email address.
2. Harriet sends your message and waits. The workflow pauses at this point; no one monitors the thread manually.
3. Harriet asks follow-up questions. If the reply is incomplete or ambiguous, it follows up before moving on.
4. Harriet returns a structured summary. When the conversation is complete, the result passes to the next step and the workflow continues.

The contacted person receives a normal Slack DM or email from Harriet and replies as they normally would; no special app or link is required. When the conversation ends, Harriet sends a brief closing message.

Every data-gathering conversation resolves to one of three outcomes. Either all the information is gathered and the workflow continues with the summary; or the information is partial or the contact is unresponsive, in which case Harriet sends a polite closing message and hands control back to the linked ticket so your team decides what happens next; or nothing is gathered, which hands back the same way rather than looping indefinitely.

A restricted agent, by design

The data-gathering agent cannot access your knowledge base or employee records. It can only send messages and receive replies. This is intentional: data-gathering steps contact people who may be outside the ticket, or outside your organization entirely, and the restriction means Harriet cannot accidentally relay sensitive internal data to them. The full isolation model is described in Designing complex flows.

Designing clean pause-and-resume flows

Good pause and resume design keeps runs predictable and prevents duplicate tickets and "is anything happening?" confusion.

• Ask one thing at a time. Request missing facts in small chunks (dates, IDs, approvals) rather than ten questions at once, and say who should answer and by when if you have SLAs.
• Pick the right wait mechanism. If the person is already on the ticket thread, a ticket reply wait is natural. If a human check is needed before Harriet sends email or updates a system, use an approval step rather than a plain message. Use a data-gathering step when the person is outside the current thread.
• Keep context in the ticket. When the workflow resumes it should see the full thread; avoid parallel email chains the workflow cannot read.
• Make resume behavior explicit. After a reply arrives, the agent resumes with full context of everything that happened before, so design each step to state what happens next: confirm receipt, post a summary, or route internally.

Example

A vendor onboarding workflow needs the account owner to confirm the contract start date before generating the purchase order. The step's instructions read: "Reach out to {account_owner_email} via Slack and ask them to confirm the contract start date for {vendor_name} under the agreement signed on {signature_date}." Harriet messages the account owner, they reply "Confirmed, October 1st", and the workflow continues to the purchase-order step with start_date: October 1, confirmed_by: owner@company.com, via: Slack DM.