FlowRunner
PricingContact
Theme
Start Free

Disciple.Tools

CRM

Connect AI agents to a self-hosted Disciple.Tools site, the open source WordPress CRM for ministry and outreach. Agents create contacts, groups, and records, post comments, manage who a record is shared with, and read the activity log behind each change.

23 actions Basic auth available
A registration list, an inbound message, or a scheduled sweep starts the run
Get Record Settings returns the exact status and path keys this instance actually uses
Create Contact runs with Check For Duplicates on `contact_phone,contact_email` so returning people are matched
Update Contact sets the assignment and overall status using the instance's own keys
Add Comment logs the outreach note on the record so the history stays with the person
The assigned coach is told they have a new person and what has happened so far
A person approves any Remove Share before someone loses sight of a contact they are walking with

What This Integration Enables

Disciple.Tools is self hosted, and that single fact governs everything about how an agent should behave here. There is no vendor operated address to point at, so you supply your own Instance URL and the connector authenticates as a WordPress user with an Application Password sent as HTTP Basic credentials. Actions run with exactly the permissions of the user who owns that password, which means the right setup is a dedicated integration user with the roles it genuinely needs and nothing more. The data on the other side is not a sales pipeline. It is a record of relationships with real people, held by a ministry that chose to host it themselves specifically so that nobody else holds it. An automation that treats that database like a CRM to be optimised has misread the room.

So the connector is built around reading the instance before writing to it. Fields such as overall_status, seeker_path, group_status, and group_type are configured per site, which is why they are plain text parameters rather than fixed dropdowns, and Get Record Settings is the action that lists the exact keys and labels a given instance accepts. Create Contact and Create Record take a Check For Duplicates list of comma separated field keys, and when a match is found the existing record comes back instead of a new one being created, so matching is part of the write rather than a separate sweep afterwards. The Fields format has real shape to it: text and key_select fields are plain values, communication channels such as contact_phone and contact_email are arrays of { value } objects, and multi-select, connection, tags, and location_grid fields use a { values: [ { value } ] } structure where a { value, delete: true } entry removes a value. Silent can be set on create and update to suppress notifications and comment activity for a change, which is useful for a backfill and inappropriate for anything a person should know about. Disciple.Tools ships no triggers to FlowRunner, so agents poll the list actions with Limit and Offset against a { posts, total } envelope, defaulting to one hundred per page with a maximum of one thousand. Notably, the dt-posts v2 API exposes no delete endpoint for a record at all, so there is no Delete Contact and no Delete Group here. The only permanent operations are Delete Comment and Remove Share, and that is where the digital andon cord hangs.

Without FlowRunner

Every instance is different An integration written against one site's status keys silently mismatches on the next
Returning people become duplicates The same person registers twice and ends up as two records with half a history each
Access changes happen quietly A share is removed during a cleanup and the coach who was walking with that person is never told

With FlowRunner

Configuration is read at runtime The instance's own field keys and labels are fetched before anything is written against them
Matching happens on the way in Duplicate checking on phone and email returns the existing record instead of creating a second one
Visibility changes are reviewed Share removals are assembled with the relationship history attached and approved by a person

Use Case Scenarios

Event registrants who are recognised rather than recreated

Registrations for a training event collect in Google Sheets. Before writing anything, the agent calls Get Record Settings for the contact post type to load the instance's real overall_status and seeker_path keys, because the labels a team uses locally will not match another site's. It then calls Create Contact for each row with Check For Duplicates set to contact_email,contact_phone, so people who attended a previous event come back as their existing record with their history intact instead of arriving as a second copy. New people get the source and the event name written through Additional Fields. Returning people get Add Comment noting that they registered again, which is usually the more interesting fact.

Inbound messages logged onto the right record automatically

A message arrives from a known contact through Gmail. The agent calls Advanced Search to find the matching record, then Get Contact to load the person's current status and assignment. Add Comment writes the message content onto the record so the conversation history lives with the person rather than in one volunteer's inbox. If the contact's assigned coach differs from the person who received the message, the agent calls Get Shares and Get Followers to work out who is already watching that record, and notifies them. It does not change the assignment. Deciding who walks with someone is a leadership judgment, and the agent's job is to make sure the right people know, not to reassign the relationship.

Follow up that is prompted by the record, not by memory

On a schedule, the agent calls List Contacts filtered by overall status to find people recently assigned, then Get Activity on each record to see whether anything has actually happened since the assignment. Records with an assignment and no subsequent activity past the team's threshold are grouped by assigned coach. Each coach receives a message through Twilio naming the people waiting on a first contact and how long they have been waiting. Nothing is escalated over the coach's head and no status is changed. The follow up loop stays between the coach and the person, with the automation supplying only the reminder that a busy week swallowed.

Human-in-Loop Highlight

Remove Share is the operation on this connector that cannot be undone and that costs the most when it is wrong. In Disciple.Tools a share is how a coach, a multiplier, or a team lead can see a contact at all, and the platform is deliberately restrictive about visibility because the records describe real people in situations that are sometimes sensitive. Removing a share does not delete anything, which is exactly why it is easy to treat as a low stakes tidy up. What it actually does is take a person off the record of somebody they may be actively walking with, permanently and, if the flow has Silent set, without generating any notification or activity comment at all. The coach simply opens the app one day and the contact is not there. There is no undo action on this connector to reverse it, and the record's own delete does not exist either, so the relationship history stays in the database with fewer people able to reach it. So an access cleanup agent gathers evidence and stops. It calls Get Shares and Get Followers on each record, Get Activity to see who has actually been engaged recently, and Get Comments to see who has been writing notes, then posts to the ministry lead: "The quarterly access review flags 34 shares on contacts assigned to people who left the team. 26 of those coaches have no activity on the record in six months. 8 have commented in the last month, including 3 on contacts whose overall status changed in the same period. Remove the 26, and leave the 8 for you to speak to?" The lead answers, and Remove Share runs on the approved set only, with Silent left off so the change is visible in the activity log afterwards. The point of the gate is not caution for its own sake. It is that the difference between a departed volunteer and an active one is legible in the comments, and only a person who knows the team can read it correctly.

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

Contacts

4
  • List Contacts Returns contacts with Limit and Offset paging against a `{ posts, total }` envelope, default page size one hundred and maximum one thousand. Used for status sweeps and coverage reporting.
  • Get Contact Retrieves a single contact with its full field set. Used to load current status and assignment before any decision is made about the record.
  • Create Contact Creates a contact, exposing common fields directly and accepting an Additional Fields object for everything else. Accepts a Check For Duplicates list of field keys such as `contact_phone,contact_email`, returning the existing record when a match is found instead of creating a second one.
  • Update Contact Updates a contact using the Disciple.Tools fields format, where communication channels are arrays of `{ value }` objects and multi-select and connection fields use a `{ values: [ { value } ] }` shape. Silent can be set to suppress notifications for the change.

Groups

4
  • List Groups Returns groups with Limit and Offset paging. Used to report on teams, churches, and other group types configured on the instance.
  • Get Group Retrieves a single group with its membership and status. Used to load context before writing to it.
  • Create Group Creates a group, with common fields exposed directly and an Additional Fields object for the rest. Used to register a new team or church as it forms.
  • Update Group Updates a group, including membership through the fields format, where a `{ value, delete: true }` entry removes a value from a connection or multi-select field.

Records, Any Post Type

6
  • List Records Returns records of any post type on the instance, including custom types, with Limit and Offset paging. Used when a site has defined post types beyond contacts and groups.
  • Get Record Retrieves a single record of any post type. Used to load the full field set before an update decision.
  • Create Record Creates a record of any post type from a full Fields object, and accepts Check For Duplicates so a match returns the existing record. Used to work with custom post types no fixed object model would cover.
  • Update Record Updates a record of any post type from a full Fields object. Used to write outcomes back to custom types as work completes elsewhere.
  • Advanced Search Searches across records. Used to resolve a person or a group from an inbound message before logging anything against them.
  • Get Record Settings Returns the field keys and labels a post type accepts on this instance, including the configured values for fields such as `overall_status`, `seeker_path`, `group_status`, and `group_type`. This is the read that makes every subsequent write correct on a site the connector has never seen.

Comments

4
  • Get Comments Returns the comments on a record. Used to judge whether a record is being actively worked and by whom.
  • Add Comment Adds a comment to a contact or group. Used to log outreach notes, inbound messages, and follow up detail on the record itself rather than in a personal inbox.
  • Update Comment Edits an existing comment. Used to correct a logged note without removing the entry from the history.
  • Delete Comment Deletes a comment permanently. There is no undo, so removals are assembled and reviewed rather than run inline.

Activity

1
  • Get Activity Returns the activity log for a record. Used to detect assignments with no follow up and to drive reminders and reporting without changing anything.

Shares and Followers

4
  • Get Shares Returns who a record is currently shared with. Used as the evidence for any access review before a change is proposed.
  • Add Share Shares a record with a user so the right coach or multiplier can see it. Used when an assignment changes or a new person joins a team.
  • Remove Share Removes a share permanently. This takes a person's visibility of a contact away with no undo, and with Silent set it generates no notification, so it runs only on a set a person has approved.
  • Get Followers Returns the users following a record. Used alongside Get Shares to understand who would actually notice a change before one is made.

Frequently Asked Questions

What can FlowRunner do with Disciple.Tools?

FlowRunner agents can run List Contacts, Get Contact, and Create Contact in Disciple.Tools, plus 20 more actions.

Does connecting Disciple.Tools to FlowRunner require OAuth?

No. Disciple.Tools connects to FlowRunner with basic authentication (a username and password), no OAuth flow required.

Can Disciple.Tools trigger a FlowRunner workflow automatically?

Disciple.Tools doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Disciple.Tools

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