The Platform, Access & Integrations workspace brings accessibility support,
developer tools, data portability, and plan controls together without
weakening the privacy rules of the products that own the underlying records.
Help Members Shape Their Experience
Members open Profile > Access & data in the mobile app to choose text size,
contrast, reading presentation, reduced motion, audio-first use, language,
caption language, Data Saver, and optional image loading. These device choices
apply across the app and continue to work when the network is unavailable.
Members can also record a large-print bulletin need, interpreter request,
mobility help, audio description, sensory information, dietary or allergy
information, and other support notes. Those details are private by default.
They appear to an authorized church support team only after the member turns
on sharing. Requesting help also requires that explicit sharing choice.
Access notes can help a church prepare, but they are not an emergency or
medical service. Keep urgent safeguarding, medical, and emergency needs in the
workflow responsible for them.
Respond to Access Requests
Staff with Platform access support permission open Platform, Access &
Integrations > Member access. The queue contains only profiles members have
chosen to share. Staff can acknowledge or resolve a request without adding its
private narrative to general member search, analytics, or audit descriptions.
The same section holds the church’s default language, access-support email, and
low-bandwidth stream fallback. Export retention belongs in Data & plan.
Provider setup stays in the product that uses it, so administrators do not have
two competing places to manage the same connection. For example:
- Giving providers remain in Giving settings.
- Messaging providers remain in Communications or Marketing.
- Streaming providers remain in Streaming and media settings.
- Imports remain in the member-data migration workflow.
The Platform workspace keeps cross-product developer controls such as
automation connections, the public API, and outgoing webhooks.
Automate with Zapier or Make
Sign in to your church at app.thefaithapp.com,
then open Platform, Access & Integrations > Developers.
Your church needs the Large or Enterprise plan, which includes Platform
Integrations. Your staff account needs Platform — Integrations & Webhooks
permission and permission for the records used by the workflow. Ask your church
administrator for access if the workspace or required key permissions are
missing.
Zapier is available by invitation. TheFaithApp remains private on Zapier
and is not listed in its public App Directory. Public listing is deferred
while churches begin using the integration.Make is also available by invitation. Its public directory review has
been submitted and is pending with Make. You can use the invitation while
that review is in progress.
Connect Your Church
- In Developers, choose Create automation key and give it a name for the
connection, such as
Visitor welcome.
- Select only the permissions that workflow needs. Triggers need Enable
automation triggers plus read access for the relevant area. Actions need
their relevant write or message permission. You can grant only permissions
you already have in TheFaithApp.
- Set an expiry when the connection is temporary. The date uses your browser’s
local time; the saved expiry appears beside the key in Developers.
- Copy the key when it is shown, then enter it in the TheFaithApp connection
in Zapier or Make. Use this automation key, rather than your church’s member
sign-in client key. The full key cannot be shown again.
- Name the provider connection for your church and check the church returned
by its connection test. Choose a trigger and action, test with a suitable
record, and enable the workflow in the automation provider.
Both integrations connect to your live church. Action tests can create or
change records, and message tests can send real messages. Use a suitable test
person or event, or choose Return Success to check a connection without
changing church records.
Triggers include new members, visitors, received donations, event
registrations, prayer-request metadata, serving accepts and declines, and form
submission metadata. Actions can create or update a person, add a tag or group
membership, register a person for an event, or send a message through the
church’s configured channels.
Prayer and form triggers exclude private narratives and answers. Donation
triggers exclude donor identity. Message sending uses the church’s existing
channels. Email respects recorded opt-outs, and SMS requires confirmed consent.
Check that a visitor has agreed to receive follow-up before adding a message.
Example: Welcome a New Visitor
Create a key with Enable automation triggers, New visitor information,
and Create, update, and tag people. In Zapier, use New Visitor or Connect
Card, then Create or Update Person. In Make, use Watch new visitors or
connect cards, then Create or update a person.
Map the visitor’s recorded name and contact details, and use the trigger’s
event ID as the action’s Source event ID to prevent duplicates on retries.
Add a welcome message only when your church has the required channel setup
and the visitor’s recorded email consent is enabled.
Choose the Right Make Connection
Name each Make connection for its church and use that church’s automation key.
Check the church returned by the connection test before choosing people,
groups, or events. Changing churches in TheFaithApp does not change the
connection already selected in a Make scenario.
Make connects to your live TheFaithApp church. Create the key in that church,
and treat action tests as real changes to its records. Use a suitable test
person or event before enabling a workflow for other members. Testing a message
action can send a real message through the church’s configured channel.
Use the standard actions for visitor follow-up and other supported workflows.
The advanced Make an API call option uses the same connection and
permissions for additional supported requests. Ask your platform administrator
for help with the request and keep the same source event ID if you retry an
action.
Test Without Changing Church Data
Choose Return Success as the final action when you want to test a trigger
without creating people, changing records, or sending messages. Select your
church connection; current Zapier and Make versions check that it is still
authorized before returning success. The check reads connection information
without changing church records. It does not confirm that a different action
would succeed. Older private Zapier versions return success without checking
the connection.
Keep a Zapier test workflow to two steps: one trigger and one action. For
example, use Schedule by Zapier > Every Hour, then TheFaithApp > Return
Success. To test a TheFaithApp trigger, choose that trigger first and Return
Success second. Turn off a temporary scheduled Zap after testing.
Review and Stop a Workflow
The Developers section shows key use and recent action outcomes. Open webhook
diagnostics to review delivery attempts and failures. Repeated requests with
the same source event ID reuse the saved action result.
If a message’s delivery outcome is uncertain, review it before deliberately
trying again with a new event ID; otherwise the recipient could receive it
twice. Revoke a key when the workflow ends or the key is exposed. Revocation
also stops its webhook subscriptions. To replace a key, create a new one,
update the provider connection, then revoke the old one.
Send Signed Webhooks
An integration administrator can add an HTTPS endpoint, choose Event,
registration, and Giving event types, and send a safe test event. The signing
secret is displayed only when the endpoint is created or the secret is
rotated. Copy it immediately to the receiving system.
Failed deliveries are retried with the same event identifier, and an
administrator can retry a delivery manually. Giving payloads contain status
and financial identifiers needed for reconciliation, not donor identity.
Webhook receivers must use a public HTTPS address; local and private network
destinations are refused.
Export Church Data
An administrator with Platform data export permission can request one full
church export from Data & plan. The ZIP contains a manifest and
machine-readable files for church-owned relational records. It excludes or
redacts passwords, API keys, provider credentials, tokens, sessions, queue
internals, and webhook secrets.
The export is private, tenant-scoped, audited, and available only until the
displayed expiry. Download it before that time and keep the copy according to
your church’s records and privacy policy.
Change or Cancel a Plan
Base plans are month to month and have no termination fee. A user with
Platform billing management permission can cancel the current paid base
plan in one action. Cancellation moves the church to Free and stops future
base-plan renewal without deleting church records, donation history, or giving
provider connections. Existing add-on access remains available through its
already-paid period.
Create and download a full export before leaving if the church needs an
independent copy of its records.
What Remains Gated
Real-time sermon translation is still a separate low-latency streaming and
live-caption workflow. The platform’s AI Assistance safeguards are available,
but they do not yet provide that live audio pipeline. Published transcript
translations, captions, multi-language content, campus workflows, and
first-party clearance status continue to work now. 