# Zapier and Make Automations
Source: https://docs.thefaithapp.com/api-reference/automation

Authenticate scoped automation connections, browse church records, subscribe to documented event payloads, and safely retry actions.

> [!NOTE]
>
> Zapier is available by invitation and remains private. Make is also available
> by invitation while its public directory review is pending. For invitation
> access and church setup, see [Platform, Access and
> Integrations](/product/platform-access-integrations#automate-with-zapier-or-make).

Automation connections use dedicated keys created in **Platform > Developers**.
Send the full secret as `X-API-Key`. These keys are different from the public
church API key used by member applications. Keys are bound to a church, have
explicit scopes, and can expire or be revoked. The issuing staff member's
current permissions also limit delegated access.

The production API base URL is `https://api.thefaithapp.com/api/automation/v1`.
All paths below are relative to that base unless shown in full. Send
`Accept: application/json`; JSON writes also use `Content-Type: application/json`.
The church is selected by the key. Do not send a church ID to switch tenants.
The church's plan must include Platform Integrations.

## Verify a Connection

`GET /auth` returns HTTP `200` for an active connection:

```json theme={null}
{
  "data": {
    "id": "5fc07b7b-0f8a-48fa-a027-1dff582e1249",
    "name": "Example Church",
    "key_id": "7dbbccdc-4737-4d97-86ad-ce529e82cb5a",
    "scopes": ["triggers:read", "members:read", "people:write"]
  }
}
```

| Response field | Type | Meaning |
| - | - | - |
| `data.id` | UUID string or `null` | The church's public identifier; a legacy church may not have one |
| `data.name` | string | Church name, suitable for the connection label |
| `data.key_id` | UUID string | Public identifier of the automation key; never the secret |
| `data.scopes` | array of strings | Scopes allowed by both the key and its issuing staff member's current permissions |

This endpoint does not require a trigger or action scope. An expired or revoked
key returns `401`; a church plan without Platform Integrations returns `403`.
Successful authenticated requests update the key's last-used timestamp.

## Browse People, Groups, and Events

These read-only endpoints provide IDs and names for workflow selectors:

| Method and path | Required scope: at least one listed | Records returned |
| - | - | - |
| `GET /options/members` | `members:read` or `people:write` | People in the key's church |
| `GET /options/groups` | `groups:write` | Active community groups in the key's church |
| `GET /options/events` | `events:read` or `events:write` | Events in the key's church |

Each endpoint accepts the same optional query parameters:

| Parameter | Type | Rules |
| - | - | - |
| `search` | string or `null` | Maximum 100 characters; matches the person's/group's name or event title |
| `page` | integer | At least `1`; default `1` |

Results are sorted by name or event title, with up to 100 records per page.
Soft-deleted records are excluded. The events list is a selector, so a listed
event is not a guarantee that registration is available. Registration rules
are checked when an action runs.

For example, `GET /options/members?search=Example&page=1` returns HTTP `200`:

```json theme={null}
{
  "data": [{ "id": 123, "name": "Example Person" }],
  "meta": { "current_page": 1, "has_more": false }
}
```

| Response field | Type | Meaning |
| - | - | - |
| `data` | array | Matching records; empty when there are no matches |
| `data[].id` | integer | Numeric person, group, or church event ID to map into an action |
| `data[].name` | string | Person/group name, or the event title |
| `meta.current_page` | integer | The page returned |
| `meta.has_more` | boolean | Request `page + 1` when `true` |

The same response shape applies to all three endpoints. Unknown resource paths
return `404`; a missing effective scope returns `403`; invalid query parameters
return `422`.

## Connection and Triggers

| Method and path | Purpose |
| - | - |
| `GET /api/automation/v1/auth` | Verify the connection and return its church and effective scopes |
| `GET /api/automation/v1/events?type={type}` | Poll recent events of one allowed trigger type |
| `GET /api/automation/v1/events/{uuid}` | Read one retained event owned by the church, subject to its trigger scopes |
| `POST /api/automation/v1/subscriptions` | Subscribe a public HTTPS target to one trigger |
| `DELETE /api/automation/v1/subscriptions/{uuid}` | Stop a subscription owned by this key |

Supported trigger types are `member.created`, `visitor.created`,
`giving.received`, `event.registration.created`, `prayer.request.created`,
`volunteer.assignment.accepted`, `volunteer.assignment.declined`, and
`form.submitted`. Trigger access requires `triggers:read` and the corresponding
`members:read`, `visitors:read`, `giving:read`, `events:read`, `prayer:read`,
`volunteers:read`, or `forms:read` scope.

Polling returns an array in `data`. Each event has a stable `id` for provider
deduplication and a numeric `cursor_id`. Without `since_id`, results are newest
first. With `since_id`, results are ascending after that cursor. Advance the
cursor only after durable processing. `limit` is at most 100. Events remain
available for the configured retention window, 30 days by default; polling is
not a full historical export.

| Polling query parameter | Type | Rules |
| - | - | - |
| `type` | string | Required; one of the eight supported trigger types |
| `limit` | integer | `1`–`100`; default `100` |
| `since_id` | integer | Optional cursor, at least `0`; use a prior numeric `cursor_id` |
| `event_id` | UUID string | Optional filter for one retained automation event |

The list response also contains `meta.next_cursor` (the largest returned
numeric cursor, or `null` for an empty list) and `meta.retention_days` (integer).
For example:

```json theme={null}
{
  "data": [
    {
      "id": "e317e867-bc2b-4e2b-b23c-8a275ef7cb67",
      "type": "member.created",
      "created_at": "2026-10-08T09:00:00.000Z",
      "data": {
        "member_id": 123,
        "uuid": "7dbbccdc-4737-4d97-86ad-ce529e82cb5a",
        "name": "Example Person",
        "email": "person@example.org",
        "phone": null,
        "source": "admin"
      },
      "cursor_id": 456
    }
  ],
  "meta": { "next_cursor": 456, "retention_days": 30 }
}
```

The optional `event_id` query parameter accepts one UUID and filters this same
list response to that retained event. Use it with `type` for a fixed-path
readback request; a missing or foreign event returns an empty `data` array.
Malformed identifiers return `422`. Make uses this form so incoming webhook
values never become part of its request path.

Create a REST hook with this body:

```json theme={null}
{
  "event_type": "visitor.created",
  "target_url": "https://receiver.example.com/thefaithapp",
  "name": "Visitor welcome"
}
```

The response contains `data.id` and `data.signing_secret`. Store the secret
securely and verify [webhook signatures](/api-reference/platform-access-and-webhooks#verify-a-delivery).
Repeated subscriptions for the same key, event type, and target reuse the
existing subscription. Targets must pass the public HTTPS address checks.
Revoking a key stops its subscriptions and pending deliveries.

The native Make connector uses its dedicated webhook URL and fetches the
canonical event through authenticated event readback before processing it.
Keep that URL private and deduplicate external workflow steps by event ID.
Authenticated readback does not prevent an exposed URL from replaying a known
event. Generic webhook receivers should verify the signed body as described above.

Prayer and form events omit private text and answers. Giving events omit donor
identity. Keep event identifiers when retrying and deduplicate at the receiver.

## Trigger Payload Contracts

All eight trigger types use this common event envelope. The tables below
describe the fields inside its `data` object; they are not additional top-level
fields. Examples on this page are illustrative, not customer records.

| Envelope field | Type | Meaning |
| - | - | - |
| `id` | UUID string | Stable automation event ID, used for deduplication and readback |
| `type` | string | Exact trigger type |
| `created_at` | ISO 8601 date-time string | Time the automation event was recorded |
| `data` | object | The trigger-specific snapshot described below |
| `cursor_id` | integer | Numeric polling cursor, present in `GET /events` list results only |

A webhook delivery contains `id`, `type`, `created_at`, and `data`.
`GET /events/{uuid}` returns that event inside `{"data": {...}}`, without a
`cursor_id`. Polling and the fixed-path `GET /events?type=...&event_id=...`
readback return a list, with `cursor_id` on each event. The automation event
UUID is different from `data.event_id`, which identifies a church event.
Treat each payload as the snapshot recorded when the event was published.

Zapier's instant triggers use the event UUID and signed snapshot. Their setup
samples remove only the list-specific `cursor_id` so they match live webhook
results. The numeric cursor remains available to direct API polling clients.

### New Member: `member.created`

Requires `triggers:read` and `members:read`. Published when a person is created
in a church or assigned to a destination church. Later profile edits do not
replace the original snapshot.

| Data field | Type | Meaning |
| - | - | - |
| `member_id` | integer | Numeric person ID |
| `uuid` | UUID string or `null` | Person's public identifier |
| `name` | string | Person's name |
| `email` | string or `null` | Recorded email address |
| `phone` | string or `null` | Recorded phone number |
| `source` | string or `null` | Source recorded on the person |

### New Visitor: `visitor.created`

Requires `triggers:read` and `visitors:read`.

| Data field | Type | Meaning |
| - | - | - |
| `visitor_id` | integer | Numeric visitor ID |
| `uuid` | UUID string | Visitor's public identifier |
| `member_id` | integer or `null` | Linked person, if present |
| `first_name` | string | Visitor's first name |
| `last_name` | string or `null` | Visitor's last name |
| `email` | string or `null` | Recorded email address |
| `phone` | string or `null` | Recorded phone number |
| `source` | string | Recorded source, such as `connect_card` |
| `email_consent` | boolean | Whether email consent was recorded |
| `sms_consent` | boolean | Whether SMS consent was recorded |

Recorded contact details alone are not consent to send messages. Filter a
welcome workflow on the relevant consent value.

### Donation Received: `giving.received`

Requires `triggers:read` and `giving:read`. Published for settled general gifts
and outreach donations marked `donated`. The `source` value distinguishes two
payload variants; source-specific fields are absent from the other variant.

| Data field | Type | Meaning |
| - | - | - |
| `source` | string | `general` or `outreach_campaign` |
| `id` | integer | Donation ID within that source; use `source` together with this ID |
| `reference` | string or `null` | Recorded gift/payment reference |
| `status` | string | Recorded donation status |
| `amount` | decimal string | Recognized amount, or recorded amount when no recognized amount is set |
| `currency` | string or `null` | Recorded currency code |
| `refunded_amount` | decimal string | Refunded amount recorded in this snapshot |
| `settled_at` | ISO 8601 date-time string or `null` | Recorded settlement time |
| `fund_id` | integer or `null` | General gifts only: fund ID |
| `disputed_amount` | decimal string | General gifts only: recorded disputed amount |
| `campaign_id` | integer | Outreach donations only: campaign ID |
| `type` | string | Outreach donations only: `cash` or `item` |

For example, the `data` object for a general gift is:

```json theme={null}
{
  "source": "general",
  "id": 123,
  "reference": "EXAMPLE-GIFT",
  "status": "completed",
  "fund_id": 1,
  "amount": "25.00",
  "currency": "USD",
  "refunded_amount": "0.00",
  "disputed_amount": "0.00",
  "settled_at": "2026-10-08T09:00:00.000Z"
}
```

Donor names, email addresses, member IDs, and payment credentials are excluded.
This trigger is a received-gift snapshot, not a stream of subsequent refunds
or disputes.

### New Event Registration: `event.registration.created`

Requires `triggers:read` and `events:read`.

| Data field | Type | Meaning |
| - | - | - |
| `id` | integer | Registration ID |
| `public_uuid` | UUID string | Registration's public identifier |
| `event_id` | integer | Church event ID; different from the envelope's automation event UUID |
| `event_public_uuid` | UUID string or `null` | Church event's public identifier |
| `occurrence_date` | `YYYY-MM-DD` string or `null` | Registered occurrence |
| `status` | string | Registration status, such as `registered` or `waitlist` |
| `payment_status` | string | Recorded payment status, such as `not_required` or `pending` |
| `party_size` | integer | One registrant plus guest count |
| `checked_in` | boolean | Check-in state in the creation snapshot |

Registrant identity, contact details, and registration notes are excluded.

### New Prayer Request: `prayer.request.created`

Requires `triggers:read` and `prayer:read`. This is a metadata-only trigger.

| Data field | Type | Meaning |
| - | - | - |
| `prayer_request_id` | integer | Prayer request ID |
| `visibility` | string | Recorded visibility, such as `pastoral` |
| `is_anonymous` | boolean | Whether the request is anonymous |
| `status` | string | Recorded request status |

The payload excludes names, member IDs, prayer text, and pastoral notes,
including for requests that are not anonymous.

### Serving Assignment Accepted: `volunteer.assignment.accepted`

Requires `triggers:read` and `volunteers:read`. Published when the assignment
has a recorded response time and the status is `confirmed`.

| Data field | Type | Meaning |
| - | - | - |
| `assignment_id` | integer | Assignment ID |
| `public_uuid` | UUID string | Assignment's public identifier |
| `member_id` | integer or `null` | Assigned person |
| `service_plan_id` | integer | Service plan ID |
| `status` | string | `confirmed` |
| `response` | string | `accepted` |
| `responded_at` | ISO 8601 date-time string | Recorded response time |

### Serving Assignment Declined: `volunteer.assignment.declined`

Requires `triggers:read` and `volunteers:read`. Published when the assignment
has a recorded response time and the status is `declined`.

| Data field | Type | Meaning |
| - | - | - |
| `assignment_id` | integer | Assignment ID |
| `public_uuid` | UUID string | Assignment's public identifier |
| `member_id` | integer or `null` | Assigned person |
| `service_plan_id` | integer | Service plan ID |
| `status` | string | `declined` |
| `response` | string | `declined` |
| `responded_at` | ISO 8601 date-time string | Recorded response time |

Serving response payloads exclude private leader notes and instructions.

### Form Submitted: `form.submitted`

Requires `triggers:read` and `forms:read`. Published when a submission has a
recorded submission time and is not marked as spam.

| Data field | Type | Meaning |
| - | - | - |
| `submission_id` | integer | Submission ID |
| `public_uuid` | UUID string | Submission's public identifier |
| `form_id` | integer | Form ID |
| `completion_status` | string | Recorded completion status |
| `submitted_at` | ISO 8601 date-time string | Recorded submission time |

Answers, attachments, member identities, and care information are excluded.

## Actions and Retry Safety

Use `POST /api/automation/v1/actions/{action}` with JSON input and an
`Idempotency-Key` header. The key must contain 1–200 printable ASCII characters
without spaces or other whitespace
and stay the same for every retry of that source event and action.

| Action | Required scope |
| - | - |
| `person.upsert` | `people:write` |
| `person.tag` | `people:write` |
| `group.add_member` | `groups:write` |
| `event.register` | `events:write` |
| `message.send` | `messages:send` |

The native connectors also offer **Return Success**. Both versions return
`{"id":"thefaithapp-return-success","success":true}` without changing church
records or creating an automation action run. Neither uses a backend action
endpoint or requires an action scope.

Zapier's publication version 1.0.4 and Make require the selected church
connection and check it with read-only `GET /api/automation/v1/auth`. They return
success only after HTTP 200, without exposing the authentication response or
key. This check can update the key's last-used metadata. Neither version
confirms that another action would succeed. The private Zapier version 1.0.3
returns success locally without checking authentication.

For example:

```http theme={null}
POST /api/automation/v1/actions/person.upsert
X-API-Key: <automation-secret>
Idempotency-Key: <visitor-event-id>
Content-Type: application/json
```

```json theme={null}
{
  "name": "Example Visitor",
  "email": "visitor@example.com"
}
```

`person.upsert` creates new people with the `automation` source. When updating
an existing person by member ID or matching email, it preserves their original
source. Email matching is case-insensitive within the key's church.

Retries with identical input return the saved response with
`Idempotency-Replayed: true`. Reusing a key with changed input returns `409`.
A request already processing also returns `409`; do not use a new key to
bypass it. The claim is scoped to the church, credential, and action.

External email and SMS providers may accept a message before a network failure
prevents confirmation. Such actions are marked `review_required` and replay
their saved failure rather than sending again. Review the provider outcome
before intentionally submitting a new request. A new idempotency key is a new
action and can create a duplicate.

Message actions use the church's existing channel configuration. Email honors
recorded opt-outs; SMS requires confirmed consent. Visitor welcome workflows
should filter on recorded email consent before sending follow-up.
Event registrations respect capacity, deadline, occurrence, and
registration settings. Resource IDs must belong to the key's church.

## Action Request and Response Contracts

All five endpoints below require `X-API-Key`, an `Idempotency-Key` header, and
a JSON body. The source ID belongs in the header, not in the JSON body.
Successful requests return HTTP `200` with this envelope:

```json theme={null}
{
  "data": { "id": 123, "member_id": 123, "tag": "Welcome" },
  "run_id": "e317e867-bc2b-4e2b-b23c-8a275ef7cb67"
}
```

`run_id` is the UUID of the saved automation action run. The fields inside
`data` depend on the action as documented below. An idempotent replay returns
the original saved result and original HTTP status, with
`Idempotency-Replayed: true`.

Optional fields may be omitted or sent as `null` unless a conditional
requirement is listed. Required numeric resource IDs are integers of at least
`1` and must belong to the key's church. These endpoints do not accept a church
override or an arbitrary recipient email/phone.

### Create or Update Person: `POST /actions/person.upsert`

Required scope: `people:write`.

| Input field | Type | Required | Rules |
| - | - | - | - |
| `member_id` | integer or `null` | No | Existing person ID, at least `1`; when supplied, selects the person to update |
| `name` | string | Yes | Maximum 255 characters; saved with leading/trailing whitespace removed |
| `email` | string or `null` | When `member_id` is empty | Valid email, maximum 255 characters; matched case-insensitively within this church |
| `phone` | string or `null` | No | Maximum 20 characters |

Without a member ID, a matching email updates that person; otherwise a new
person is created if the church has member capacity. Updating a person's
email to one already used by someone else in the church returns `422`.
Omitting email or phone on an ID-based update preserves that value; supplying
`null` clears it. New people use the `automation` source; updates preserve the
original source.

| Result field in `data` | Type | Meaning |
| - | - | - |
| `id` | integer | Person ID |
| `member_id` | integer | Same person ID, suitable for other actions |
| `uuid` | UUID string or `null` | Person's public identifier |
| `name` | string | Saved name |
| `email` | string or `null` | Saved email |
| `phone` | string or `null` | Saved phone |

### Add Person Tag: `POST /actions/person.tag`

Required scope: `people:write`.

| Input field | Type | Required | Rules |
| - | - | - | - |
| `member_id` | integer | Yes | Person ID, at least `1` |
| `tag` | string | Yes | Maximum 40 characters; must contain text |

Whitespace is trimmed and collapsed. Matching an existing tag is
case-insensitive and returns it without adding a duplicate. A person can have
up to 20 tags; adding a new tag at that limit returns `422`.

| Result field in `data` | Type | Meaning |
| - | - | - |
| `id` | integer | Saved tag record ID |
| `member_id` | integer | Person ID |
| `tag` | string | Saved tag text, including the existing spelling when reused |

### Add Person to Group: `POST /actions/group.add_member`

Required scope: `groups:write`.

| Input field | Type | Required | Rules |
| - | - | - | - |
| `member_id` | integer | Yes | Person ID, at least `1` |
| `group_id` | integer | Yes | Active community group ID, at least `1` |

An existing active membership is returned unchanged. A new membership uses
the `member` role and does not opt the person into the group directory.

| Result field in `data` | Type | Meaning |
| - | - | - |
| `id` | integer | Group membership ID |
| `member_id` | integer | Person ID |
| `group_id` | integer | Community group ID |
| `status` | string | Membership status, normally `active` |

### Create Event Registration: `POST /actions/event.register`

Required scope: `events:write`.

| Input field | Type | Required | Rules |
| - | - | - | - |
| `member_id` | integer | Yes | Person ID, at least `1`; recorded name and email supply registrant details |
| `event_id` | integer | Yes | Church event ID, at least `1` |
| `occurrence_date` | `YYYY-MM-DD` string or `null` | No | Must be a valid event occurrence; omission selects the next upcoming occurrence |
| `guests` | integer or `null` | No | `0`–`100`; default `0`; party size is `1 + guests` |
| `meal_count` | integer or `null` | No | `0`–`100`; default `0`; saved only when the event collects meal counts |
| `childcare_count` | integer or `null` | No | `0`–`100`; default `0`; saved only when the event collects childcare counts |
| `options` | array of strings or `null` | No | At most 50 values, each at most 100 characters; only configured event option keys are retained |
| `notes` | string or `null` | No | Maximum 2,000 characters; saved only when the event collects special notes |

Use an explicit occurrence date for predictable recurring-event workflows.
The event must support built-in registration and its deadline must not have
passed. Capacity and waitlist settings apply. Existing uncancelled registration
for the same person and occurrence is returned unchanged. A cancelled
registration can be reopened with the new input.

A paid registration can return `payment_status: "pending"`; this action does
not charge the person or complete payment. Paid registration requires the
church's Stripe connection to be ready. Read the returned status before
treating the person as registered or paid.

| Result field in `data` | Type | Meaning |
| - | - | - |
| `id` | integer | Registration ID |
| `public_uuid` | UUID string | Registration's public identifier |
| `member_id` | integer | Person ID |
| `event_id` | integer | Church event ID |
| `occurrence_date` | `YYYY-MM-DD` string or `null` | Resolved occurrence date |
| `status` | string | Saved registration status, such as `registered` or `waitlist` |
| `payment_status` | string | Saved payment status, such as `pending`, `paid`, or `not_required` |
| `amount_due` | decimal string | Recorded registration amount |
| `currency` | string | Recorded currency code |

### Send Message: `POST /actions/message.send`

Required scope: `messages:send`. The issuing staff member must also retain the
permission for the selected channel.

| Input field | Type | Required | Rules |
| - | - | - | - |
| `member_id` | integer | Yes | Person ID, at least `1`; destination comes from that person |
| `channel` | string | Yes | `in_app`, `email`, or `sms` |
| `subject` | string or `null` | For `in_app` and `email` | Maximum 255 characters; optional for SMS |
| `body` | string | Yes | Maximum 5,000 characters |

In-app messages create a notification for the selected person. Email requires
a valid recorded recipient, an active church email provider, a valid sender,
and no recorded subscriber opt-out. SMS requires a recorded phone number and
a subscribed SMS record with confirmed opt-in. Email/SMS actions make real
external sends through the church's provider.

| Result field in `data` | Type | Meaning |
| - | - | - |
| `id` | UUID string | Created in-app notification ID, or generated result ID for email/SMS; not a provider delivery receipt |
| `member_id` | integer | Person ID |
| `channel` | string | `in_app`, `email`, or `sms` |
| `status` | string | `sent`; the in-app notification was created or the provider confirmed the send request |

An email/SMS success does not prove that the person read or received the
message. Ambiguous provider failures return `502` with a saved action run that
needs review; use the retry guidance above before starting a new send.

## Make an API Call

Make's **Make an API call** module uses the selected connection and the
production Automation API. Enter a relative path such as `/v1/auth` or
`/v1/events`, and put filters in **Query string**. For an action request, map
the stable **Source event ID**; the module sends it as `Idempotency-Key`.

The optional **Headers** input accepts only `X-Request-ID` and
`X-Correlation-ID` for request tracing. The connection supplies `X-API-Key`,
`Accept`, and the JSON `Content-Type`; these and `Idempotency-Key` cannot be
overridden through **Headers**.

The output contains **Body**, **Status code**, and a **Headers** collection
limited to `Content-Type` and `Retry-After` when present. Other response headers,
including cookies and authentication or credential values, are excluded from
the module's mapped output. Log sanitization is separate from this restriction
on scenario bundles. Use `Retry-After` to guide retries when the API rate-limits
a request.

## Errors and Diagnostics

Error responses contain `message`. Validation failures can also contain
`errors`, whose keys identify invalid fields and whose values are arrays of
messages. Once an action run has been claimed, its response includes `run_id`;
authentication, scope, and initial input-validation failures can occur before
a run exists.

| HTTP status | Meaning | Next step |
| - | - | - |
| `401` | Key is invalid, expired, or revoked, or its issuing account no longer has access | Reconnect with an active authorized key |
| `403` | Effective scope, staff permission, channel permission, or church plan does not permit this request | Check the key, issuing staff permissions, and plan |
| `404` | Resource is missing, belongs to another church, or is no longer retained; or the action/path is unknown | Verify the resource and path in this church |
| `409` | Source ID was used with different input, or its action is still processing | Inspect the existing run; do not bypass it with a new source ID |
| `422` | Input, consent, capacity, occurrence, or provider settings need correction | Read `message` and any field-level `errors` |
| `429` | Request rate limit exceeded | Honor `Retry-After` when present and use exponential backoff with jitter |
| `502` | Action outcome could not be confirmed and the saved run needs review | Inspect the provider and run before deliberately submitting another send |

An empty `GET /events?event_id=...` list is HTTP `200` when the UUID does not
match a retained event for the requested type and church. Direct
`GET /events/{uuid}` readback returns `404` for a missing, foreign, or expired
event. Do not automatically retry a `review_required` message action as a new
request.

Integration administrators can review recent action runs in **Developers**
and webhook attempts in webhook diagnostics. Private provider invite links
are configured per deployment; an account or local app definition alone does
not make a provider app available to churches.


# Connected Calendars
Source: https://docs.thefaithapp.com/api-reference/connected-calendars

Authorize Google or Outlook calendars and synchronize church schedules and member serving responses.

The connected-calendar API uses Composio-hosted OAuth links. Provider tokens
stay with Composio. TheFaithApp stores encrypted connected-account metadata
and tenant-bound mappings rather than accepting provider account IDs from
the client.

## Routes and Ownership

Staff routes use a staff bearer token:

* `/api/events/calendar-connections` manages the church organizer connection
  and requires Events permission.
* `/api/volunteer/calendar-connections` manages the authenticated staff
  member's own calendar. The staff email must be verified and match a member
  record in the same church.

Member routes use the authenticated member session:

* `/api/member/calendar-connections`
* `/v2/volunteer/calendar-connections`

Each route family supports:

| Method and suffix | Purpose |
| - | - |
| `GET /` | List owned connections, provider availability, run history, and own assignments |
| `POST /` | Start or reconnect with `provider: google` or `provider: outlook` |
| `POST /{uuid}/refresh` | Verify OAuth completion and the expected provider, auth configuration, and user |
| `GET /{uuid}/calendars` | List accessible calendars and whether they can be edited |
| `PUT /{uuid}` | Choose `calendar_id`, `include_events`, and `include_serving` |
| `POST /{uuid}/retry` | Queue a sync after a calendar is selected |
| `DELETE /{uuid}` | Revoke upstream authorization and stop future synchronization |

Member route families also support
`POST /assignments/{uuid}/respond` with `response: confirmed` or
`response: declined`. A decline requires `reason`. The assignment must belong
to that member and church.

## Synchronization Contract

TheFaithApp remains the schedule source. Registered member events and eligible
published serving assignments are mirrored to the selected member calendar.
Church connections mirror published events and serving plans. Internal notes,
safeguarding data, and unrelated calendars are excluded.

Stable mappings update an existing provider event when times or locations
change, and remove only mapped events after cancellation. Provider event
creation uses deterministic IDs or transaction identifiers to avoid duplicate
creates after an ambiguous response. Timezones are included explicitly.

For native serving RSVPs, a church organizer connection and the member's
active, opted-in serving connection must use the same provider. The member's
verified connected account email is the attendee. Only the mapped organizer
event's response for that attendee can change the assignment. A copied
personal appointment uses a TheFaithApp response link instead; deleting or
editing it is not an RSVP.

Sync is queued after relevant changes and polled by the scheduler. Provider
limits and authorization failures appear in connection status and run history.
Run the queue worker and Laravel scheduler for synchronization to continue.
Disconnect immediately stops local synchronization, attempts to delete mapped
provider entries, and revokes upstream access. Failed cleanup can leave entries
in the provider and is shown in connection status. Switching a selected calendar
removes its mapped entries before creating the new set.

## Calendar Response Links

Personal appointment copies include a temporary signed response link to the
Next.js frontend at
`/calendar/serving-response/{connectionUuid}/{assignmentUuid}`. The page shows
assignment details and records a response only after an explicit form submit.
It requires no staff login. The frontend calls the calendar response API from
the server; provider tokens and staff credentials are not sent to the page.

The API supports `GET` and `POST` at
`/api/calendar/serving-response/{connectionUuid}/{assignmentUuid}`. Both require
the original query string, in this order:
`expires=<unix timestamp>&signature=<64 lowercase hexadecimal characters>`.
The signature covers the relative API path and expiry. Extra or duplicate
query parameters are rejected. The signed link authorizes only that assignment
in the connection's church; client and member selectors are not accepted.

`GET` returns `success: true` and a `data` object containing `title`, `role`,
`starts_at`, `ends_at`, `timezone`, `location`, `status`, `saved`, and
`can_respond`. Timestamps are UTC ISO values with the plan's IANA timezone
provided for display; timestamps and location may be null. GET has no response
side effects and returns `saved: false`.

`POST` accepts JSON:

```json theme={null}
{
  "response": "declined",
  "reason": "I am unavailable on that date."
}
```

Use `confirmed` to accept or `declined` to decline. A decline requires a reason
of at most 2,000 characters. A successful POST returns the same data contract
with `saved: true`. A confirmed assignment may be declined later. Declined
assignments return `can_respond: false`; changing one back to confirmed returns
HTTP 409. Repeated responses use the existing assignment response service.

Invalid or expired signatures return HTTP 403. Revoked connections, mismatched
ownership, or assignments no longer available return HTTP 404. Validation
errors return HTTP 422; the per-capability rate limit returns HTTP 429. Private
responses and redirects use `no-store`, `no-referrer`, and `noindex` headers.

Existing absolute signed links on the API host at
`/calendar/serving-response/{connectionUuid}/{assignmentUuid}` remain valid until
their original expiry. GET validates the old link and redirects to the frontend
with a new relative API signature **without extending that expiry**. The legacy
POST remains CSRF-protected and returns JSON. Laravel no longer renders the
member response page.

Treat each link as a private bearer capability: anyone who receives it can
respond for that assignment. It becomes invalid when its connection is revoked.
Keep signed URLs and decline reasons out of logs, analytics, and error reports;
application telemetry suppresses these fields, but proxy and access-log query
retention must also be configured by the deployment operator.

## Deployment

Configure server-only `COMPOSIO_API_KEY`,
`COMPOSIO_GOOGLE_CALENDAR_AUTH_CONFIG_ID`, and
`COMPOSIO_OUTLOOK_AUTH_CONFIG_ID`. Optional `COMPOSIO_BASE_URL` defaults to
Composio's API host. Staff OAuth redirects use `DASHBOARD_URL`; member redirects
use the trusted TheFaithApp app link back to the Volunteer Hub. Set
`FRONTEND_URL` to the installation's HTTPS Next.js origin for serving response
links, and `APP_URL` to the correct API origin for existing absolute signatures.
Deploy the frontend page and JSON API together before testing new or legacy
calendar response links.

For Google, calendar-list read access and event read/write access are required.
For Outlook, use calendar read/write and account profile access with refresh
authorization. Grant actual provider data access only through the end user's
OAuth consent flow. Providers with missing configuration are unavailable in
the dashboard.


# Discipleship API availability
Source: https://docs.thefaithapp.com/api-reference/discipleship

Understand the current public integration boundary for TheFaithApp Discipleship.

# Discipleship API availability

Discipleship is available in TheFaithApp's first-party admin dashboard and
member apps. It is **not currently included in the supported public partner
`v1` API**.

That means a partner app cannot yet use the public API to load pathways,
submit quizzes, update progress, manage mentorship, or participate in private
formation practices.

> [!WARNING]
>
> Do not call admin dashboard routes or internal mobile routes from a partner
> app. They use first-party authentication, permissions, and privacy rules and
> may change without a partner API version transition.

## Supported today

| Need | Recommended approach |
| - | - |
| Church staff create and manage Discipleship content | Use the TheFaithApp admin dashboard |
| Members take classes and use formation practices | Use the TheFaithApp member app |
| A person verifies a completion certificate | Open the public verification link printed on the certificate |
| A partner app needs supported TheFaithApp data | Use only endpoints listed in this `v1` API reference |

Certificate verification links are public product links. A person does not
need dashboard access to verify a certificate. This does not make the wider
Discipleship data model a public API.

## Why the boundary matters

Discipleship includes unusually sensitive data: private journals, spiritual
goals, Examen responses, fast choices, Rule of Life commitments, and mentor
check-ins. A public contract needs explicit scopes, consent behavior, owner-only
authorization, retention guarantees, and safe error responses before it can be
offered to partners.

## What not to do

* Do not copy a bearer token or cookie from the first-party apps.
* Do not scrape the admin dashboard or mobile responses.
* Do not store correct quiz answers in a client bundle.
* Do not recreate staff access to private member formation data.
* Do not treat an internal route path as a stable API contract.

## Prepare for a future integration

You can design your application so a future supported API is easier to adopt:

1. Use [Hosted Auth](/api-reference/hosted-auth) for member identity where your
   current integration already uses supported `v1` endpoints.
2. Keep church and member identifiers opaque; do not derive meaning from them.
3. Separate shared learning progress from private spiritual reflection in your
   own data model.
4. Build explicit consent and revocation into any feature that shares formation
   data.
5. Subscribe to the [Changelog](/changelog) for new public API capabilities.

> [!NOTE]
>
> Hosted Auth does not grant access to Discipleship by itself. It is listed
> here only as the supported identity pattern for existing partner APIs.

## Requesting access

If Discipleship integration is important to your church or product, contact
[support@thefaithapp.com](mailto:support@thefaithapp.com) with the member
workflow, data you need, and how you plan to protect private formation data.
That information helps shape a safe future public contract.


# Get Member Access Profile
Source: https://docs.thefaithapp.com/api-reference/endpoints/access-&-inclusion/get-member-access-profile

/api-reference/openapi.json get /v1/platform/access-profile
Returns the authenticated member’s app preferences, member-owned accessibility-support details, church language settings, and available offline capabilities. Support details are never exposed through a staff API unless the member explicitly shares them.



# Update Member Access Profile
Source: https://docs.thefaithapp.com/api-reference/endpoints/access-&-inclusion/update-member-access-profile

/api-reference/openapi.json put /v1/platform/access-profile
Updates member-owned display, language, bandwidth, and accessibility-support preferences. Set `share_with_support_team` before using `request_support`; turning sharing off removes the profile from the staff support queue.



# Batch Track Analytics
Source: https://docs.thefaithapp.com/api-reference/endpoints/analytics/batch-track-analytics

/api-reference/openapi.json post /v1/analytics/batch-track
Records several analytics events in one request. Each item returns an independent success or failure result.



# End Analytics Session
Source: https://docs.thefaithapp.com/api-reference/endpoints/analytics/end-analytics-session

/api-reference/openapi.json post /v1/analytics/session/end
Closes an analytics session owned by the authenticated member and church.



# Start Analytics Session
Source: https://docs.thefaithapp.com/api-reference/endpoints/analytics/start-analytics-session

/api-reference/openapi.json post /v1/analytics/session/start
Starts or reuses a client-generated analytics session.



# Track Content View
Source: https://docs.thefaithapp.com/api-reference/endpoints/analytics/track-content-view

/api-reference/openapi.json post /v1/analytics/track/content-view
Records a view of church content.



# Track Feature Usage
Source: https://docs.thefaithapp.com/api-reference/endpoints/analytics/track-feature-usage

/api-reference/openapi.json post /v1/analytics/track/feature-usage
Records an action in a named product feature.



# Track Media Play
Source: https://docs.thefaithapp.com/api-reference/endpoints/analytics/track-media-play

/api-reference/openapi.json post /v1/analytics/track/media-play
Records media playback.



# Track Notification Clicked
Source: https://docs.thefaithapp.com/api-reference/endpoints/analytics/track-notification-clicked

/api-reference/openapi.json post /v1/analytics/notifications/track/clicked
Records that a notification was clicked. Duplicate events are handled idempotently.



# Track Notification Delivered
Source: https://docs.thefaithapp.com/api-reference/endpoints/analytics/track-notification-delivered

/api-reference/openapi.json post /v1/analytics/notifications/track/delivered
Records that a notification was delivered. Duplicate events are handled idempotently.



# Track Notification Opened
Source: https://docs.thefaithapp.com/api-reference/endpoints/analytics/track-notification-opened

/api-reference/openapi.json post /v1/analytics/notifications/track/opened
Records that a notification was opened. Duplicate events are handled idempotently.



# Track Page View
Source: https://docs.thefaithapp.com/api-reference/endpoints/analytics/track-page-view

/api-reference/openapi.json post /v1/analytics/track/page-view
Records a page view.



# Get Church Branches
Source: https://docs.thefaithapp.com/api-reference/endpoints/churches/get-church-branches

/api-reference/openapi.json get /v1/branches
Retrieve a paginated list of branches for the authenticated user's church. Supports optional pagination.



# Get Church Name
Source: https://docs.thefaithapp.com/api-reference/endpoints/churches/get-church-name

/api-reference/openapi.json get /v1/client/{uuid}/name
Returns the display name for a church public UUID.



# Get Church Profile
Source: https://docs.thefaithapp.com/api-reference/endpoints/churches/get-church-profile

/api-reference/openapi.json get /v1/church
Returns the authenticated member’s church profile, social links, branches, gatherings, and hosted action URLs. Open `church.giving_link` for member giving.



# Get Public Church Profile
Source: https://docs.thefaithapp.com/api-reference/endpoints/churches/get-public-church-profile

/api-reference/openapi.json get /v1/churches/public/{uuid}
Returns the public church profile used before a member subscribes or switches context.



# List Churches
Source: https://docs.thefaithapp.com/api-reference/endpoints/churches/list-churches

/api-reference/openapi.json get /v1/churches
Returns the public church directory with optional search and pagination.



# Comment On A Community Group Post
Source: https://docs.thefaithapp.com/api-reference/endpoints/community-groups/comment-on-a-community-group-post

/api-reference/openapi.json post /v1/community-groups/{groupId}/feed/posts/{postId}/comments
Adds a comment to a post visible to an active member of the group.



# Create A Community Group Leader Note
Source: https://docs.thefaithapp.com/api-reference/endpoints/community-groups/create-a-community-group-leader-note

/api-reference/openapi.json post /v1/community-groups/{groupId}/leader-notes
Creates a private group leader note, optionally associated with an active group member.



# Create A Community Group Post
Source: https://docs.thefaithapp.com/api-reference/endpoints/community-groups/create-a-community-group-post

/api-reference/openapi.json post /v1/community-groups/{groupId}/feed/posts
Publishes a discussion or, for authorized group leaders, an announcement.



# Create A Community Group Study Guide
Source: https://docs.thefaithapp.com/api-reference/endpoints/community-groups/create-a-community-group-study-guide

/api-reference/openapi.json post /v1/community-groups/{groupId}/study-guides
Publishes a study guide for the group. Only group leaders, co-leaders, and hosts may perform this action.



# Get A Community Group
Source: https://docs.thefaithapp.com/api-reference/endpoints/community-groups/get-a-community-group

/api-reference/openapi.json get /v1/community-groups/{groupId}
Returns one active community group in the member’s church together with the member’s current membership state.



# Get Community Group Feed
Source: https://docs.thefaithapp.com/api-reference/endpoints/community-groups/get-community-group-feed

/api-reference/openapi.json get /v1/community-groups/{groupId}/feed
Returns group posts, comments, and study guides for an active group member.



# Join A Community Group
Source: https://docs.thefaithapp.com/api-reference/endpoints/community-groups/join-a-community-group

/api-reference/openapi.json post /v1/community-groups/{groupId}/join
Joins an open group or submits an approval request for a request-to-join group.



# Leave A Community Group
Source: https://docs.thefaithapp.com/api-reference/endpoints/community-groups/leave-a-community-group

/api-reference/openapi.json delete /v1/community-groups/{groupId}/membership
Ends the authenticated member’s membership and synchronizes linked group chat access.



# List Community Group Leader Notes
Source: https://docs.thefaithapp.com/api-reference/endpoints/community-groups/list-community-group-leader-notes

/api-reference/openapi.json get /v1/community-groups/{groupId}/leader-notes
Returns private leader notes for the selected group. Only group leaders, co-leaders, and hosts may view them.



# List Community Groups
Source: https://docs.thefaithapp.com/api-reference/endpoints/community-groups/list-community-groups

/api-reference/openapi.json get /v1/community-groups
Lists active community groups in the authenticated member’s church with membership state and optional filters.



# Record Community Group Attendance
Source: https://docs.thefaithapp.com/api-reference/endpoints/community-groups/record-community-group-attendance

/api-reference/openapi.json post /v1/community-groups/{groupId}/attendance
Creates or updates attendance records for active group members. Only group leaders, co-leaders, and hosts may perform this action.



# Record Community Group Attendance (Compatibility)
Source: https://docs.thefaithapp.com/api-reference/endpoints/community-groups/record-community-group-attendance-compatibility

/api-reference/openapi.json get /v1/community-groups/{groupId}/attendance
Compatibility alias for recording attendance. This GET mutation is deprecated; integrations should use POST on the same path.



# Get Communication Preferences
Source: https://docs.thefaithapp.com/api-reference/endpoints/community-preferences-&-research/get-communication-preferences

/api-reference/openapi.json get /v1/community/communication-preferences
Returns quiet hours, timezone, and topic-level community notification preferences for the authenticated member.



# Get Community Coordination Profile
Source: https://docs.thefaithapp.com/api-reference/endpoints/community-preferences-&-research/get-community-coordination-profile

/api-reference/openapi.json get /v1/community/coordination-profile
Returns the authenticated member's consent-scoped coordination profile, active newcomer connections, and the safety guardrails applied to staff-reviewed suggestions.



# Get Community Summary
Source: https://docs.thefaithapp.com/api-reference/endpoints/community-preferences-&-research/get-community-summary

/api-reference/openapi.json get /v1/community/summary
Returns the authenticated member's group counts, mutual-aid availability, research-pilot status, and shared-resource availability.



# Get Research Consent
Source: https://docs.thefaithapp.com/api-reference/endpoints/community-preferences-&-research/get-research-consent

/api-reference/openapi.json get /v1/community/research-consent
Returns consent and eligibility information for opt-in community research pilots.



# Grant Or Update Research Consent
Source: https://docs.thefaithapp.com/api-reference/endpoints/community-preferences-&-research/grant-or-update-research-consent

/api-reference/openapi.json put /v1/community/research-consent
Opts the authenticated member into one or more enabled research pilots after explicit acceptance of the consent terms.



# Update Communication Preferences
Source: https://docs.thefaithapp.com/api-reference/endpoints/community-preferences-&-research/update-communication-preferences

/api-reference/openapi.json put /v1/community/communication-preferences
Updates quiet hours, timezone, and topic-level community notification preferences.



# Update Community Coordination Profile
Source: https://docs.thefaithapp.com/api-reference/endpoints/community-preferences-&-research/update-community-coordination-profile

/api-reference/openapi.json put /v1/community/coordination-profile
Updates only the coordination details covered by the member's current consent. Locations must remain approximate, and all resulting suggestions require staff review before an introduction.



# Withdraw Research Consent
Source: https://docs.thefaithapp.com/api-reference/endpoints/community-preferences-&-research/withdraw-research-consent

/api-reference/openapi.json delete /v1/community/research-consent
Withdraws the authenticated member from all community research pilots.



# Get Audio Sermons
Source: https://docs.thefaithapp.com/api-reference/endpoints/content/get-audio-sermons

/api-reference/openapi.json get /v1/audios
Retrieve a paginated list of audio sermons for the authenticated user's church. Supports optional search and pagination.



# Get Devotionals
Source: https://docs.thefaithapp.com/api-reference/endpoints/content/get-devotionals

/api-reference/openapi.json get /v1/devotionals
Retrieve devotionals for the authenticated user's church. When X-Client-Date header is provided, returns a single devotional for that date with metadata. Otherwise, returns a paginated list of devotionals.



# Get Live Streamings
Source: https://docs.thefaithapp.com/api-reference/endpoints/content/get-live-streamings

/api-reference/openapi.json get /v1/streamings
Retrieve the current live video and audio streaming information for the authenticated user's church.



# Get Sermon Chapters
Source: https://docs.thefaithapp.com/api-reference/endpoints/content/get-sermon-chapters

/api-reference/openapi.json get /v1/media/{mediaId}/chapters
Fetch published chapter markers for a sermon in the authenticated member's church. Returns data: null when no published chapters are available.



# Get Sermon Insights
Source: https://docs.thefaithapp.com/api-reference/endpoints/content/get-sermon-insights

/api-reference/openapi.json get /v1/media/{mediaId}/insights
Fetch published sermon summary, key points, scripture references, reflection questions, and discussion prompts for a sermon in the authenticated member's church. Returns data: null when no published insights are available.



# Get Sermon Transcript
Source: https://docs.thefaithapp.com/api-reference/endpoints/content/get-sermon-transcript

/api-reference/openapi.json get /v1/media/{mediaId}/transcript
Fetch the published synced transcript for an audio or uploaded video sermon in the authenticated member's church. Returns data: null when no published transcript is available.



# Get Single Devotional
Source: https://docs.thefaithapp.com/api-reference/endpoints/content/get-single-devotional

/api-reference/openapi.json get /v1/devotionals/{id}
Fetches a full devotional payload by ID.



# Get Video Sermons
Source: https://docs.thefaithapp.com/api-reference/endpoints/content/get-video-sermons

/api-reference/openapi.json get /v1/videos
Retrieve a paginated list of video sermons for the authenticated user's church. Supports optional search and pagination.



# List Church YouTube Videos
Source: https://docs.thefaithapp.com/api-reference/endpoints/content/list-church-youtube-videos

/api-reference/openapi.json get /v1/youtube/videos
Returns videos from the authenticated church's configured YouTube playlist or channel.



# List Media by Category
Source: https://docs.thefaithapp.com/api-reference/endpoints/content/list-media-by-category

/api-reference/openapi.json get /v1/media/category/{categoryId}
Returns paginated church media in a category. `client_id` is currently required in addition to the authenticated church context.



# List Videos from a YouTube URL
Source: https://docs.thefaithapp.com/api-reference/endpoints/content/list-videos-from-a-youtube-url

/api-reference/openapi.json get /v1/youtube/external
Resolves a public YouTube playlist or channel URL and returns its videos in the standard media shape.



# Get Current User
Source: https://docs.thefaithapp.com/api-reference/endpoints/core-experience/get-current-user

/api-reference/openapi.json get /v1/user
Returns the authenticated member profile together with the active church context.



# Get Home Feed
Source: https://docs.thefaithapp.com/api-reference/endpoints/core-experience/get-home-feed

/api-reference/openapi.json get /v1/home
Loads the member-facing home payload, including church context, content, and the latest bulletin.



# Set Active Church
Source: https://docs.thefaithapp.com/api-reference/endpoints/core-experience/set-active-church

/api-reference/openapi.json post /v1/set-client-id
Moves the authenticated member into a church context. The selected church must match the API key used for subsequent requests.



# Subscribe to Church
Source: https://docs.thefaithapp.com/api-reference/endpoints/core-experience/subscribe-to-church

/api-reference/openapi.json post /v1/subscribe
Subscribes the authenticated TheFaithApp member to the church represented by the client API key and stores the device FCM token for push notifications.



# Update Member Profile
Source: https://docs.thefaithapp.com/api-reference/endpoints/core-experience/update-member-profile

/api-reference/openapi.json put /v1/member
Canonical alias for `PUT /v1/member/details`. Updates fields on the authenticated member profile.



# Update Member Profile Details (Legacy)
Source: https://docs.thefaithapp.com/api-reference/endpoints/core-experience/update-member-profile-details-legacy

/api-reference/openapi.json put /v1/member/details
Compatibility route for updating the authenticated member profile. New integrations should use `PUT /v1/member`.



# Add Bookmark
Source: https://docs.thefaithapp.com/api-reference/endpoints/engagement/add-bookmark

/api-reference/openapi.json post /v1/bookmarks
Adds a devotional to the authenticated member's bookmarks.



# Add Favorite
Source: https://docs.thefaithapp.com/api-reference/endpoints/engagement/add-favorite

/api-reference/openapi.json post /v1/favorites
Adds a media item to the authenticated member's favorites.



# List Bookmarks
Source: https://docs.thefaithapp.com/api-reference/endpoints/engagement/list-bookmarks

/api-reference/openapi.json get /v1/bookmarks
Lists the devotional bookmarks saved by the authenticated member.



# List Favorites
Source: https://docs.thefaithapp.com/api-reference/endpoints/engagement/list-favorites

/api-reference/openapi.json get /v1/favorites
Lists the favorite media items saved by the authenticated member.



# Remove Bookmark
Source: https://docs.thefaithapp.com/api-reference/endpoints/engagement/remove-bookmark

/api-reference/openapi.json delete /v1/bookmarks
Removes a devotional from the authenticated member's bookmarks.



# Remove Favorite
Source: https://docs.thefaithapp.com/api-reference/endpoints/engagement/remove-favorite

/api-reference/openapi.json delete /v1/favorites
Removes a media item from the authenticated member's favorites.



# Cancel Own Event Registration
Source: https://docs.thefaithapp.com/api-reference/endpoints/events-&-volunteers/cancel-own-event-registration

/api-reference/openapi.json delete /v1/events/{event}/registrations/{registration}
Cancels a registration owned by the authenticated member. Cancelling can promote an eligible waitlisted party.



# Cancel Volunteer Signup
Source: https://docs.thefaithapp.com/api-reference/endpoints/events-&-volunteers/cancel-volunteer-signup

/api-reference/openapi.json delete /v1/volunteer/signups/{id}
Cancels a volunteer signup owned by the authenticated member.



# Check In Own Event Registration
Source: https://docs.thefaithapp.com/api-reference/endpoints/events-&-volunteers/check-in-own-event-registration

/api-reference/openapi.json post /v1/events/{event}/registrations/{registration}/self-check-in
Checks in a registration owned by the authenticated member while the event self-check-in window is open. Paid registrations must be provider-confirmed first.



# Get Events
Source: https://docs.thefaithapp.com/api-reference/endpoints/events-&-volunteers/get-events

/api-reference/openapi.json get /v1/events
Retrieve a paginated list of events for the authenticated user's church. Supports optional pagination.



# List Event Categories
Source: https://docs.thefaithapp.com/api-reference/endpoints/events-&-volunteers/list-event-categories

/api-reference/openapi.json get /v1/event-categories
Returns event categories available to the authenticated member's church.



# List My Volunteer Commitments
Source: https://docs.thefaithapp.com/api-reference/endpoints/events-&-volunteers/list-my-volunteer-commitments

/api-reference/openapi.json get /v1/volunteer/my-commitments
Returns the authenticated member's volunteer signups.



# List Volunteer Categories
Source: https://docs.thefaithapp.com/api-reference/endpoints/events-&-volunteers/list-volunteer-categories

/api-reference/openapi.json get /v1/volunteer/categories
Returns volunteer categories configured for the authenticated church.



# List Volunteer Ministries
Source: https://docs.thefaithapp.com/api-reference/endpoints/events-&-volunteers/list-volunteer-ministries

/api-reference/openapi.json get /v1/volunteer/ministries
Returns volunteer ministries configured for the authenticated church.



# List Volunteer Opportunities
Source: https://docs.thefaithapp.com/api-reference/endpoints/events-&-volunteers/list-volunteer-opportunities

/api-reference/openapi.json get /v1/volunteer/opportunities
Returns active volunteer opportunities for the authenticated church.



# Register For Event
Source: https://docs.thefaithapp.com/api-reference/endpoints/events-&-volunteers/register-for-event

/api-reference/openapi.json post /v1/events/{event}/register
Registers the authenticated member and their party for one event occurrence. The server derives member and church ownership from the credentials. Capacity is party-aware and may return a waitlisted registration.



# Sign Up for Volunteer Opportunity
Source: https://docs.thefaithapp.com/api-reference/endpoints/events-&-volunteers/sign-up-for-volunteer-opportunity

/api-reference/openapi.json post /v1/volunteer/opportunities/{id}/signup
Creates a pending or approved volunteer commitment for the authenticated member.



# Complete Hosted Auth Sign-In
Source: https://docs.thefaithapp.com/api-reference/endpoints/hosted-auth/complete-hosted-auth-sign-in

/api-reference/openapi.json post /v1/auth/complete
Verifies the Firebase ID token produced by the hosted sign-in page and returns a callback URL containing a short-lived authorization code.



# Create Hosted Auth URL
Source: https://docs.thefaithapp.com/api-reference/endpoints/hosted-auth/create-hosted-auth-url

/api-reference/openapi.json post /v1/auth/start
Creates a hosted sign-in URL after validating the public client key, exact Redirect URL, state, and required S256 PKCE challenge.



# Exchange Hosted Auth Code
Source: https://docs.thefaithapp.com/api-reference/endpoints/hosted-auth/exchange-hosted-auth-code

/api-reference/openapi.json post /v1/auth/token
Exchanges a short-lived, single-use hosted auth code using the original S256 PKCE verifier and exact Redirect URL.



# Get Hosted Auth Configuration
Source: https://docs.thefaithapp.com/api-reference/endpoints/hosted-auth/get-hosted-auth-configuration

/api-reference/openapi.json get /v1/auth/config
Returns public church branding, enabled sign-in providers, and whether a redirect URL is allowed.



# Sign Out Hosted Auth Member
Source: https://docs.thefaithapp.com/api-reference/endpoints/hosted-auth/sign-out-hosted-auth-member

/api-reference/openapi.json post /v1/auth/logout
Revokes the current TheFaithApp member bearer token. Call this when the member signs out of your app.



# Connect To A Campus
Source: https://docs.thefaithapp.com/api-reference/endpoints/member-connections/connect-to-a-campus

/api-reference/openapi.json post /v1/member-connections/campuses/{branchId}
Creates or updates the authenticated member’s connection to a church campus. Church settings determine whether approval is required.



# Connect To A Ministry
Source: https://docs.thefaithapp.com/api-reference/endpoints/member-connections/connect-to-a-ministry

/api-reference/openapi.json post /v1/member-connections/ministries/{ministryId}
Creates or updates the authenticated member’s connection to a ministry. Church settings determine whether approval is required.



# Get Member Connections
Source: https://docs.thefaithapp.com/api-reference/endpoints/member-connections/get-member-connections

/api-reference/openapi.json get /v1/member-connections
Returns the authenticated member’s active and pending campus, ministry, and community-group connections plus available connection options.



# Leave A Campus
Source: https://docs.thefaithapp.com/api-reference/endpoints/member-connections/leave-a-campus

/api-reference/openapi.json delete /v1/member-connections/campuses/{branchId}
Ends the authenticated member’s connection to the selected campus.



# Leave A Ministry
Source: https://docs.thefaithapp.com/api-reference/endpoints/member-connections/leave-a-ministry

/api-reference/openapi.json delete /v1/member-connections/ministries/{ministryId}
Ends the authenticated member’s connection to the selected ministry and synchronizes linked chat access.



# Accept A Mutual-Aid Response
Source: https://docs.thefaithapp.com/api-reference/endpoints/mutual-aid/accept-a-mutual-aid-response

/api-reference/openapi.json post /v1/mutual-aid-posts/{post}/responses/{response}/accept
Accepts a pending response on a post owned by the authenticated member.



# Close A Mutual-Aid Post
Source: https://docs.thefaithapp.com/api-reference/endpoints/mutual-aid/close-a-mutual-aid-post

/api-reference/openapi.json post /v1/mutual-aid-posts/{post}/close
Closes a mutual-aid post owned by the authenticated member.



# Create A Mutual-Aid Post
Source: https://docs.thefaithapp.com/api-reference/endpoints/mutual-aid/create-a-mutual-aid-post

/api-reference/openapi.json post /v1/mutual-aid-posts
Creates a need or offer. Church configuration and category rules determine whether it is published or held for review.



# Decline A Mutual-Aid Response
Source: https://docs.thefaithapp.com/api-reference/endpoints/mutual-aid/decline-a-mutual-aid-response

/api-reference/openapi.json post /v1/mutual-aid-posts/{post}/responses/{response}/decline
Declines a pending response on a post owned by the authenticated member.



# Get A Mutual-Aid Post
Source: https://docs.thefaithapp.com/api-reference/endpoints/mutual-aid/get-a-mutual-aid-post

/api-reference/openapi.json get /v1/mutual-aid-posts/{post}
Returns a visible mutual-aid post. Owners also receive private responses and their audit history.



# Get My Mutual-Aid Activity
Source: https://docs.thefaithapp.com/api-reference/endpoints/mutual-aid/get-my-mutual-aid-activity

/api-reference/openapi.json get /v1/mutual-aid-activity
Returns mutual-aid posts created by the member and responses submitted by the member.



# List Mutual-Aid Posts
Source: https://docs.thefaithapp.com/api-reference/endpoints/mutual-aid/list-mutual-aid-posts

/api-reference/openapi.json get /v1/mutual-aid-posts
Lists mutual-aid needs and offers visible to the authenticated member, ordered by urgency and recency.



# Mark A Mutual-Aid Post Fulfilled
Source: https://docs.thefaithapp.com/api-reference/endpoints/mutual-aid/mark-a-mutual-aid-post-fulfilled

/api-reference/openapi.json post /v1/mutual-aid-posts/{post}/fulfill
Marks a mutual-aid post owned by the authenticated member as fulfilled.



# Report A Mutual-Aid Post
Source: https://docs.thefaithapp.com/api-reference/endpoints/mutual-aid/report-a-mutual-aid-post

/api-reference/openapi.json post /v1/mutual-aid-posts/{post}/report
Privately reports a mutual-aid post to church staff for safety or moderation review.



# Respond To A Mutual-Aid Post
Source: https://docs.thefaithapp.com/api-reference/endpoints/mutual-aid/respond-to-a-mutual-aid-post

/api-reference/openapi.json post /v1/mutual-aid-posts/{post}/responses
Sends a private response to a mutual-aid post and starts a private coordination flow.



# Update A Mutual-Aid Post
Source: https://docs.thefaithapp.com/api-reference/endpoints/mutual-aid/update-a-mutual-aid-post

/api-reference/openapi.json put /v1/mutual-aid-posts/{post}
Updates fields on a mutual-aid post owned by the authenticated member.



# Withdraw A Mutual-Aid Response
Source: https://docs.thefaithapp.com/api-reference/endpoints/mutual-aid/withdraw-a-mutual-aid-response

/api-reference/openapi.json post /v1/mutual-aid-posts/{post}/responses/{response}/withdraw
Withdraws the authenticated member's response from a mutual-aid post.



# Batch Track Notification Analytics
Source: https://docs.thefaithapp.com/api-reference/endpoints/notification-analytics/batch-track-notification-analytics

/api-reference/openapi.json post /v1/notification-analytics/batch-track
Records multiple notification delivery, open, or click events.



# Get Notification Analytics Summary
Source: https://docs.thefaithapp.com/api-reference/endpoints/notification-analytics/get-notification-analytics-summary

/api-reference/openapi.json get /v1/notification-analytics/summary
Returns aggregate delivery, open, and click metrics for a church.



# Track Notification Click
Source: https://docs.thefaithapp.com/api-reference/endpoints/notification-analytics/track-notification-click

/api-reference/openapi.json post /v1/notification-analytics/track/click
Records a notification click event.



# Track Notification Delivery
Source: https://docs.thefaithapp.com/api-reference/endpoints/notification-analytics/track-notification-delivery

/api-reference/openapi.json post /v1/notification-analytics/track/delivery
Records a notification delivery event.



# Track Notification Open
Source: https://docs.thefaithapp.com/api-reference/endpoints/notification-analytics/track-notification-open

/api-reference/openapi.json post /v1/notification-analytics/track/open
Records a notification open event.



# Delete User Notification
Source: https://docs.thefaithapp.com/api-reference/endpoints/notifications-&-bulletins/delete-user-notification

/api-reference/openapi.json delete /v1/notifications/{notificationId}
Deletes a member-specific notification.



# Get Bulletins
Source: https://docs.thefaithapp.com/api-reference/endpoints/notifications-&-bulletins/get-bulletins

/api-reference/openapi.json get /v1/bulletins
Retrieve a paginated list of bulletins for the authenticated user's church. Bulletins can be either native (HTML content) or PDF files.



# Get Latest Bulletin
Source: https://docs.thefaithapp.com/api-reference/endpoints/notifications-&-bulletins/get-latest-bulletin

/api-reference/openapi.json get /v1/bulletins/latest
Retrieve the most recent bulletin for the authenticated user's church. Returns the latest published bulletin with all its content and sections.



# Get Notifications
Source: https://docs.thefaithapp.com/api-reference/endpoints/notifications-&-bulletins/get-notifications

/api-reference/openapi.json get /v1/notifications
Retrieve a paginated list of notifications for the authenticated user's church. Supports optional pagination.



# Get Single Bulletin
Source: https://docs.thefaithapp.com/api-reference/endpoints/notifications-&-bulletins/get-single-bulletin

/api-reference/openapi.json get /v1/bulletins/{bulletin}
Retrieve a specific bulletin by its ID for the authenticated user's church. Returns the complete bulletin with all its content and sections.



# List User Notifications
Source: https://docs.thefaithapp.com/api-reference/endpoints/notifications-&-bulletins/list-user-notifications

/api-reference/openapi.json get /v1/notifications/user
Returns member-specific notifications such as personal alerts or direct delivery events.



# Mark All Notifications As Read
Source: https://docs.thefaithapp.com/api-reference/endpoints/notifications-&-bulletins/mark-all-notifications-as-read

/api-reference/openapi.json patch /v1/notifications/read-all
Marks every member notification as read for the authenticated member.



# Mark Notification As Read
Source: https://docs.thefaithapp.com/api-reference/endpoints/notifications-&-bulletins/mark-notification-as-read

/api-reference/openapi.json patch /v1/notifications/{notificationId}/read
Marks a member notification as read.



# Create Care Request
Source: https://docs.thefaithapp.com/api-reference/endpoints/pastoral-care/create-care-request

/api-reference/openapi.json post /v1/care-requests
Shares a confidential Pastoral Care request for the authenticated member. Counseling, benevolence, and crisis requests are restricted to pastoral staff. Urgent or crisis requests require `emergency_acknowledged: true` because this workflow is not an emergency service.



# Create Private Life Moment
Source: https://docs.thefaithapp.com/api-reference/endpoints/pastoral-care/create-private-life-moment

/api-reference/openapi.json post /v1/care-life-moments/moments
Saves a member-owned private date that may generate an assigned-caregiver reminder only when the matching consent is enabled. One-time dates must be today or later.



# Create Quiet Day
Source: https://docs.thefaithapp.com/api-reference/endpoints/pastoral-care/create-quiet-day

/api-reference/openapi.json post /v1/care-life-moments/suppressions
Creates a member-owned quiet-day window that suppresses selected celebration messages. The member may separately allow a private pastoral acknowledgment and provide restricted guidance.



# Delete Private Life Moment
Source: https://docs.thefaithapp.com/api-reference/endpoints/pastoral-care/delete-private-life-moment

/api-reference/openapi.json delete /v1/care-life-moments/moments/{careLifeMoment}
Permanently deletes a private life moment owned by the authenticated member and removes its pending reminders.



# Delete Quiet Day
Source: https://docs.thefaithapp.com/api-reference/endpoints/pastoral-care/delete-quiet-day

/api-reference/openapi.json delete /v1/care-life-moments/suppressions/{careCommunicationSuppression}
Permanently deletes a quiet-day preference owned by the authenticated member.



# Get Pastoral Care Preferences
Source: https://docs.thefaithapp.com/api-reference/endpoints/pastoral-care/get-pastoral-care-preferences

/api-reference/openapi.json get /v1/care-life-moments
Returns the authenticated member’s consent settings, private life moments, quiet-day preferences, and supported option values. The response contains only records owned by that member.



# List My Care Requests
Source: https://docs.thefaithapp.com/api-reference/endpoints/pastoral-care/list-my-care-requests

/api-reference/openapi.json get /v1/care-requests
Returns every active and past Pastoral Care request owned by the authenticated member, plus the supported form options. Responses include member-safe visits, support plans, and timeline events but never staff notes, staff tasks, internal review signals, or resolution notes.



# Update Care Request
Source: https://docs.thefaithapp.com/api-reference/endpoints/pastoral-care/update-care-request

/api-reference/openapi.json put /v1/care-requests/{careRequest}
Replaces the editable fields on an open request owned by the authenticated member. Send the complete care-request payload. Resolved, withdrawn, or retention-purged requests cannot be edited.



# Update Pastoral Care Preferences
Source: https://docs.thefaithapp.com/api-reference/endpoints/pastoral-care/update-pastoral-care-preferences

/api-reference/openapi.json put /v1/care-life-moments/preferences
Updates one or more member-controlled consent and contact settings. Reminder and Care Radar consent are disabled by default. Disabling a consent also closes related pending follow-up signals.



# Update Private Life Moment
Source: https://docs.thefaithapp.com/api-reference/endpoints/pastoral-care/update-private-life-moment

/api-reference/openapi.json put /v1/care-life-moments/moments/{careLifeMoment}
Updates one or more fields on a private life moment owned by the authenticated member. Set `status` to `paused` to stop pending follow-up without deleting the date.



# Update Quiet Day
Source: https://docs.thefaithapp.com/api-reference/endpoints/pastoral-care/update-quiet-day

/api-reference/openapi.json put /v1/care-life-moments/suppressions/{careCommunicationSuppression}
Updates one or more fields on a quiet-day preference owned by the authenticated member. Set `active` to `false` to keep the record without suppressing messages.



# Withdraw Care Request
Source: https://docs.thefaithapp.com/api-reference/endpoints/pastoral-care/withdraw-care-request

/api-reference/openapi.json post /v1/care-requests/{careRequest}/withdraw
Withdraws an open request owned by the authenticated member. Withdrawal is final and schedules confidential case content for retention-based removal.



# Submit Prayer Request
Source: https://docs.thefaithapp.com/api-reference/endpoints/prayer/submit-prayer-request

/api-reference/openapi.json post /v1/prayer-requests
Creates a prayer request for the authenticated member and church.



# Get Resource Activity
Source: https://docs.thefaithapp.com/api-reference/endpoints/resource-sharing/get-resource-activity

/api-reference/openapi.json get /v1/community/resource-activity
Returns items offered by the member and loans requested by the member.



# List Shared Resources
Source: https://docs.thefaithapp.com/api-reference/endpoints/resource-sharing/list-shared-resources

/api-reference/openapi.json get /v1/community/resources
Lists reviewed shared resources visible to the authenticated member.



# Offer A Shared Resource
Source: https://docs.thefaithapp.com/api-reference/endpoints/resource-sharing/offer-a-shared-resource

/api-reference/openapi.json post /v1/community/resources
Submits a member-owned lending item for staff review before it becomes visible.



# Request A Resource Loan
Source: https://docs.thefaithapp.com/api-reference/endpoints/resource-sharing/request-a-resource-loan

/api-reference/openapi.json post /v1/community/resources/{resource}/loans
Requests to borrow an available shared resource. Repeated active requests are idempotent.



# Transition A Resource Loan
Source: https://docs.thefaithapp.com/api-reference/endpoints/resource-sharing/transition-a-resource-loan

/api-reference/openapi.json post /v1/community/resource-loans/{loan}/transition
Approves, declines, checks out, returns, or cancels a resource loan when the member has permission for that transition.



# Flutter Giving SDK
Source: https://docs.thefaithapp.com/api-reference/flutter-giving-sdk

Add authenticated general and campaign giving with Stripe, PayPal, and Flutterwave to a Flutter app.

# Add giving to a Flutter app

The `thefaithapp_giving` package renders general and campaign giving inside
your Flutter app. It uses the member session from `thefaithapp_auth`, presents
the church's active payment provider, and waits for TheFaithApp to confirm the
payment.

The package includes:

* general giving with funds, currency, frequency, memo, and fee coverage
* campaign giving with configured donor form fields
* Stripe PaymentSheet
* hosted PayPal and Flutterwave checkout
* checkout cancellation and expiry handling
* an extension point for future payment providers

> [!NOTE]
>
> TheFaithApp creates and verifies each checkout and processes provider webhooks.
> Do not add payment-provider secret keys or webhook secrets to your mobile app.

## Before you begin

You need:

* a Flutter app targeting Android or iOS
* `thefaithapp_auth` configured with a client API key
* a signed-in TheFaithApp member
* an active payment provider configured for the church

Follow the [Flutter SDK Quickstart](/api-reference/flutter-sdk) first if member
sign-in is not working yet.

**1. Add the packages**

Add the auth and giving packages to `pubspec.yaml`:

```yaml theme={null}
dependencies:
  thefaithapp_auth: ^0.1.0
  thefaithapp_giving: ^0.2.1
```

Install them:

```bash theme={null}
flutter pub get
```

The giving package includes `flutter_stripe` and `webview_flutter`. Stop
and rebuild the app after adding it so Flutter can register their native
platform code.

**2. Check the native project**

Keep the platform requirements from the auth SDK:

* Android `minSdk` 24 or newer
* Android Internet permission in the main manifest
* Android `FlutterFragmentActivity` and AppCompat-compatible launch and normal themes
* iOS 13.0 or newer
* Keychain Sharing enabled for the iOS Runner target

Complete any additional native configuration required by
`flutter_stripe` for the platforms and wallet features your app enables.
Follow its [Android release configuration](https://github.com/flutter-stripe/flutter_stripe#android),
including the ProGuard rules, and test a full release build.
PayPal and Flutterwave use an in-app WebView and do not require provider
credentials in the application.

**3. Create the authenticated giving client**

Reuse the same auth instance that signs the member in:

```dart theme={null}
import 'package:thefaithapp_auth/thefaithapp_auth.dart';
import 'package:thefaithapp_giving/thefaithapp_giving.dart';

const clientKey = String.fromEnvironment('TFA_CLIENT_KEY');

final auth = TheFaithAppAuth(apiKey: clientKey);
final giving = TheFaithAppGiving(auth: auth);
```

Before showing protected giving:

```dart theme={null}
final session = await auth.currentSession() ?? await auth.signIn();
print('Giving as ${session.member.name}');
```

The giving client does not accept a member ID or church/client ID. The
authenticated session supplies that identity on every request.

**4. Render general giving**

Add the built-in general giving view to a page:

```dart theme={null}
GivingView.general(
  giving: giving,
  onCompleted: (result) {
    switch (result.state) {
      case GivingPaymentState.succeeded:
        // Show a thank-you state.
        break;
      case GivingPaymentState.pending:
        // Tell the member that confirmation is still processing.
        break;
      case GivingPaymentState.failed:
      case GivingPaymentState.cancelled:
        // Keep the member on a safe retry or dismissal path.
        break;
    }
  },
)
```

The view loads the church's giving settings and funds. It shows only the
currencies, recurrence options, memo, and fee coverage allowed by that
configuration.

**5. Render campaign giving**

Your app chooses the campaign, then passes its numeric ID to the view:

```dart theme={null}
GivingView.campaign(
  giving: giving,
  campaignId: 42,
  onCompleted: (result) {
    // Handle succeeded, pending, failed, or cancelled.
  },
)
```

If the campaign has donor fields, the package renders and validates its
text, multiline text, number, email, telephone, select, radio, checkbox,
and date fields.

Campaign discovery and selection belong to your app. The package begins
with the campaign ID you provide.

## Handle access failures

The error categories and fields below are available in
[`thefaithapp_giving` 0.2.0](https://pub.dev/packages/thefaithapp_giving/versions/0.2.0).

A valid sign-in does not guarantee that the church's plan includes SDK access.
Handle `GivingException.code` according to the failure:

| Code | Meaning | Next step |
| - | - | - |
| `GivingErrorCode.notAuthenticated` | No usable member session, or HTTP 401 | Follow your app's sign-in recovery path. |
| `GivingErrorCode.planAccessDenied` | HTTP 403 with a recognized plan denial | Ask the church administrator to review plan access. Signing in again does not change the plan. |
| `GivingErrorCode.forbidden` | Another HTTP 403 permission denial | Check the permitted resource/action with the church; do not assume the member needs to sign in again. |

`statusCode` retains the HTTP status. `serverErrorCode` retains a valid bounded
machine code, including `plan_product_unavailable` or
`plan_entitlement_required`. For those plan denials, optional `planAccess`
contains only typed identifiers: `type`, `product` or `entitlement`,
`currentPlan`, and `recommendedPlan`. Missing or malformed context is omitted;
it does not prevent recognizing a plan denial. No raw response or credentials
are retained in these fields.

When upgrading from 0.1.0, add the new cases to exhaustive
`GivingErrorCode` switches. The built-in view reports the error through
`onError` and displays its message; it does not sign the member out.

Use the giving constraint `^0.2.1`; the auth constraint stays `^0.1.0`.
Decoded API errors with HTTP 403 previously mapped to `notAuthenticated`.
Update exhaustive switches for `planAccessDenied` and `forbidden`, and keep
sign-in recovery for missing sessions and HTTP 401. The new
`GivingCheckoutSession.paypalSubscriptionId` field is nullable.

## Payment-provider behavior

The package uses the church's active/default provider. An app does not choose
between Stripe, PayPal, and Flutterwave for an individual gift.

| Provider | Experience |
| - | - |
| Stripe | Native PaymentSheet |
| PayPal | Hosted approval in an in-app WebView |
| Flutterwave | Hosted checkout in an in-app WebView |

The result from a native sheet or WebView is not treated as proof of payment.
The SDK checks TheFaithApp's webhook-backed status before reporting the final
state. A `pending` result means the provider or webhook is still processing.

Recurring options also depend on the provider account's capabilities.
Flutterwave recurring giving requires approval for automated tokenized card
charges; ordinary card acceptance alone does not establish that capability.

## Campaign fields

The built-in campaign view loads the campaign definition and submits its form
responses with the authenticated checkout. Required fields are validated
before the payment experience opens.

If you build a headless campaign form, send the same values with
`CampaignGivingRequest.formFields`. Do not collect or send fields that are not
part of the campaign definition.

## Recurring gifts

When recurring giving is enabled for the church and supported by its active
provider, the general and campaign views can create a recurring gift.

You can load and cancel the signed-in member's subscriptions:

```dart theme={null}
final subscriptions = await giving.getSubscriptions();

if (subscriptions.isNotEmpty) {
  await giving.cancelSubscription(subscriptions.first);
}
```

The platform scopes each subscription to its general or campaign target and
rechecks the member and church before cancellation.

For PayPal, recurring checkout creates a seller-scoped Partner Subscription.
The hosted approval result carries `paypal_subscription_id`; the SDK returns
that ID only to TheFaithApp's verification endpoint and never treats the
redirect itself as proof of payment.

## Add another payment provider

Register a `GivingPaymentHandler` whose `provider` matches the value configured
on TheFaithApp:

```dart theme={null}
final giving = TheFaithAppGiving(
  auth: auth,
  paymentHandlers: [MyPaymentHandler()],
);
```

A handler receives only one checkout's ephemeral session and narrow
capabilities for status, PayPal capture, or Flutterwave verification. It does
not receive the auth client, client API key, bearer token, member ID, or church
ID.

Never persist or log `GivingCheckoutSession` provider data. A custom handler
must return the same donation ID and provider it received.

## Cancellation and cleanup

Closing a payment experience triggers a best-effort checkout abandonment
request. If the device is offline or the app terminates before that request
arrives, TheFaithApp expires the checkout on the server. A late valid webhook
still has a short grace period so a completed payment is not incorrectly
cancelled.

## Dispose the clients

Dispose both package instances when their owning application service is
released:

```dart theme={null}
giving.dispose();
auth.dispose();
```

## Troubleshooting

| Problem | What to check |
| - | - |
| Giving says it is unavailable | Confirm the church has an active/default payment provider and supported giving configuration. |
| The member is not authenticated | Restore or create the auth session before rendering the giving view. |
| Stripe does not open | Perform a full native rebuild and complete the `flutter_stripe` platform setup. |
| A campaign cannot be loaded | Confirm the campaign ID belongs to the signed-in member's church and the campaign is available. |
| A required campaign field is missing | Render the campaign returned by the package instead of maintaining a separate field definition. |
| A payment remains pending | Keep the status message visible; TheFaithApp updates the donation when the provider webhook arrives. |

## Package resources

* [Package on pub.dev](https://pub.dev/packages/thefaithapp_giving)
* [Source and standalone example](https://github.com/thefaithapp/thefaithapp-giving-flutter)


# Flutter SDK Quickstart
Source: https://docs.thefaithapp.com/api-reference/flutter-sdk

Add hosted member sign-in to a Flutter app, meet Android and iOS requirements, restore saved sessions, and call TheFaithApp's authenticated v1 API.

# Use the API from Flutter

The `thefaithapp_auth` package signs a member in through TheFaithApp and gives
your Flutter app an authenticated client for `v1` API requests. Your app does
not need to host a callback website.

## Before you begin

You need:

* a Flutter app targeting Android or iOS
* its Android application ID or iOS bundle ID
* a client API key from `Settings > Developer Access`

**1. Add the package**

Add the package to your `pubspec.yaml`:

```yaml theme={null}
dependencies:
  thefaithapp_auth: ^0.1.0
```

Install it:

```bash theme={null}
flutter pub get
```

Stop and rebuild the app after adding the package so Flutter can register
its platform code.

**2. Register your Flutter app**

In the TheFaithApp dashboard:

1. Open `Settings > Developer Access`.
2. Click **Add Flutter app**.
3. Append `.thefaithapp` to your application ID.
4. Add the app and copy your client API key.

For an application ID of `com.example.app`, enter:

```text theme={null}
com.example.app.thefaithapp
```

The dashboard creates the callback expected by the package:

```text theme={null}
com.example.app.thefaithapp://auth/callback
```

Use a lowercase reverse-domain application ID containing letters, numbers,
and dots. Avoid underscores because they cannot be used in a callback URI
scheme.

**3. Check platform requirements**

**Android**

* Set `minSdk` to `24` or newer.
* No manual callback activity is required.

**iOS**

* Set the deployment target to iOS `13.0` or newer.
* Enable **Keychain Sharing** for the Runner target in Xcode.

No callback URL type needs to be added manually when using the package's
default system authentication session.

**4. Initialize the SDK**

Provide the client key when creating `TheFaithAppAuth`:

```dart theme={null}
import 'package:thefaithapp_auth/thefaithapp_auth.dart';

const clientKey = String.fromEnvironment('TFA_CLIENT_KEY');

final auth = TheFaithAppAuth(apiKey: clientKey);
```

Pass the value from your build environment instead of committing it to the
repository:

```bash theme={null}
flutter run \
  --dart-define=TFA_CLIENT_KEY=replace-with-your-client-key
```

**5. Sign in a member**

Open hosted sign-in from a button or another user action:

```dart theme={null}
Future<TheFaithAuthSession> signInMember() async {
  return auth.signIn();
}
```

After the member finishes signing in, the package returns to the app and
saves the session securely.

**6. Call a v1 endpoint**

Use the authorized client for protected API requests:

```dart theme={null}
import 'dart:convert';

Future<Map<String, dynamic>> loadCurrentMember() async {
  final client = auth.authorizedClient();

  try {
    final response = await client.get(auth.apiUri('/v1/user'));
    final body = jsonDecode(response.body) as Map<String, dynamic>;

    if (response.statusCode < 200 || response.statusCode >= 300) {
      throw Exception(body['message'] ?? 'The request failed.');
    }

    return Map<String, dynamic>.from(body['data'] as Map);
  } finally {
    client.close();
  }
}
```

Use `auth.apiUri('/v1/...')` for other endpoints in the API Reference.

## Restore the saved session

Check for a saved session when the app starts:

```dart theme={null}
final session = await auth.currentSession();

if (session != null) {
  print('Welcome back, ${session.member.name}');
}
```

If `currentSession()` returns `null`, show the sign-in action again.

## Sign out

Revoke the member session and remove its saved copy:

```dart theme={null}
await auth.signOut();
```

Release the SDK's resources when the owning service or widget is disposed:

```dart theme={null}
auth.dispose();
```

## Handle SDK errors

Catch `TheFaithAuthException` to show an appropriate message:

```dart theme={null}
try {
  await auth.signIn();
} on TheFaithAuthException catch (error) {
  switch (error.code) {
    case TheFaithAuthErrorCode.cancelled:
      // The member closed the sign-in session.
      break;
    default:
      // Show error.message or your own friendly message.
      break;
  }
}
```

## Troubleshooting

| Problem | What to check |
| - | - |
| The redirect is rejected | Confirm the value added with **Add Flutter app** matches the application's ID with `.thefaithapp` appended. |
| The app does not reopen after sign-in | Stop and rebuild the app, then confirm the installed app uses the expected application ID. |
| `MissingPluginException` appears | Stop the running app and perform a full rebuild after adding the package. |
| A protected request says the member is not authenticated | Call `signIn()` or restore a saved session before creating the request. |
| The session is not restored on iOS | Confirm **Keychain Sharing** is enabled for the Runner target. |

## Next steps

* Add authenticated general and campaign giving with the
  [Flutter Giving SDK](/api-reference/flutter-giving-sdk).
* Browse the endpoint groups in the API Reference navigation.
* Read [Pagination and Errors](/api-reference/pagination-and-errors) before
  loading lists or adding retry behavior.
* Use the public
  [standalone sample](https://github.com/thefaithapp/thefaithapp-auth-flutter/tree/main/example)
  as a compact reference implementation.


# Hosted Auth Guide
Source: https://docs.thefaithapp.com/api-reference/hosted-auth

Sign members into your app with TheFaithApp-hosted auth, then use member tokens for API calls.

# Hosted Auth Guide

Hosted auth lets your app sign members in without managing auth provider credentials or building your own member login screen. Your app sends the member to a TheFaithApp-hosted page, receives a one-time code on your callback URL, exchanges that code for a member token, and then uses that token for normal API calls.

## When To Use It

Use hosted auth for external web or mobile apps that need to read or update church-scoped member data through the `v1` API.

The member signs in once. After that, store the returned TheFaithApp member token securely and use it for future API calls.

## What You Need

* A client key from `Settings > Developer Access`
* One or more saved Redirect URLs
* A backend or mobile client that can exchange the returned code for a token
* A place to store the returned member token securely

## Supported Sign-In Methods

The hosted sign-in page supports:

* Google
* Apple
* Email/password sign in
* Email/password account creation with display name

New members are created automatically under the church identified by the client key. Existing members are updated from the verified sign-in profile when they sign in.

## Redirect URLs

Add every callback that can receive auth codes in `Settings > Developer Access`.

For Flutter, select **Add Flutter app** and enter your app's application ID with
`.thefaithapp` appended. For example, enter
`com.example.app.thefaithapp` for an app whose application ID is
`com.example.app`. TheFaithApp registers
`com.example.app.thefaithapp://auth/callback` automatically.

For React Native and Expo, select **Add React Native app**. Enter the same
application ID with `.thefaithapp` appended; the React Native SDK config plugin
registers the resulting callback in the native iOS and Android projects.

Examples:

```text theme={null}
https://example.com/auth/callback
https://staging.example.com/auth/callback
mychurch://auth/callback
com.example.mychurch://auth/callback
```

The `redirect_uri` you send to the API must exactly match one saved Redirect URL. If you use a mobile app, register the same deep link or app link scheme in your mobile project.

> [!NOTE]
>
> Hosted auth always runs on the TheFaithApp auth host. Church custom domains do not host the auth page.

## Full Flow

1. Generate a cryptographically random `state` value and PKCE verifier in your app.
2. Create the verifier's SHA-256 `code_challenge` and call `POST /v1/auth/start` with `code_challenge_method` set to `S256`.
3. Open the returned `auth_url` in a browser tab, mobile browser, or mobile auth session.
4. The member signs in or creates an account.
5. TheFaithApp redirects to your `redirect_uri` with `code` and `state`.
6. Confirm the returned `state` matches the one you generated.
7. Call `POST /v1/auth/token` with the one-time `code` and original `code_verifier`.
8. Store the returned `access_token`.
9. Call protected `v1` endpoints with both `X-API-Key` and `Authorization`.

```mermaid theme={null}
sequenceDiagram
    participant App as Your app
    participant API as TheFaithApp API
    participant Auth as Hosted auth page
    participant User as Member

    App->>API: POST /v1/auth/start
    API-->>App: auth_url
    App->>Auth: Open auth_url
    User->>Auth: Sign in or create account
    Auth->>API: Complete hosted auth
    API-->>Auth: redirect_to with code
    Auth-->>App: redirect_uri?code=...&state=...
    App->>API: POST /v1/auth/token
    API-->>App: access_token + member
    App->>API: GET /v1/audios with API key + bearer token
```

## 1. Start Sign-In

```bash theme={null}
curl -X POST https://api.thefaithapp.com/v1/auth/start \
  -H "Content-Type: application/json" \
  -d '{
    "client_key": "your-public-client-key",
    "redirect_uri": "https://example.com/auth/callback",
    "state": "replace-with-at-least-16-random-characters",
    "code_challenge": "base64url-sha256-of-your-code-verifier",
    "code_challenge_method": "S256"
  }'
```

Example response:

```json theme={null}
{
  "auth_url": "https://auth.thefaithapp.com/member/sign-in?client_key=your-public-client-key&redirect_uri=https%3A%2F%2Fexample.com%2Fauth%2Fcallback&state=replace-with-at-least-16-random-characters&code_challenge=base64url-sha256-of-your-code-verifier&code_challenge_method=S256",
  "client": {
    "id": 45,
    "name": "Example Church",
    "image": "clients/example-logo.png",
    "image_url": "https://cdn.example.com/clients/example-logo.png",
    "about": null,
    "public_uuid": "11111111-2222-3333-4444-555555555555"
  },
  "redirect_uri": "https://example.com/auth/callback",
  "providers": ["google", "apple", "email"]
}
```

Open `auth_url` for the member. Do not iframe the hosted auth page.

## 2. Receive The Code

After sign-in, TheFaithApp redirects back to your callback:

```text theme={null}
https://example.com/auth/callback?code=one-time-code&state=replace-with-random-state
```

Your app should:

* read `code`
* read `state`
* reject the callback if `state` does not match the value you generated
* exchange `code` immediately

Authorization codes are short-lived and can only be used once.

## 3. Exchange The Code

```bash theme={null}
curl -X POST https://api.thefaithapp.com/v1/auth/token \
  -H "Content-Type: application/json" \
  -d '{
    "client_key": "your-public-client-key",
    "code": "one-time-code",
    "redirect_uri": "https://example.com/auth/callback",
    "code_verifier": "your-original-43-to-128-character-verifier"
  }'
```

Example response:

```json theme={null}
{
  "access_token": "member-bearer-token",
  "token_type": "Bearer",
  "member": {
    "id": 123,
    "name": "Jane Member",
    "email": "jane@example.com",
    "client_id": 45,
    "uuid": "member-user-id"
  }
}
```

Store `access_token` securely. For mobile apps, use secure device storage such as Keychain or Keystore. For server-rendered web apps, keep the token server-side or in an HTTP-only secure session cookie.

## 4. Call The API

Every protected `v1` request needs both headers:

```http theme={null}
X-API-Key: your-public-client-key
Authorization: Bearer member-bearer-token
```

Example:

```bash theme={null}
curl https://api.thefaithapp.com/v1/audios?per_page=3 \
  -H "X-API-Key: your-public-client-key" \
  -H "Authorization: Bearer member-bearer-token" \
  -H "Accept: application/json"
```

## Mobile Apps

For mobile apps, use the platform's browser-based auth session:

* iOS: `ASWebAuthenticationSession`
* Android: Chrome Custom Tabs or the AppAuth browser flow
* React Native or Flutter: use a browser auth/session package that supports callback URLs

Use a redirect URL your app can receive, such as an app link, universal link, or custom scheme. The exact value must be saved in Developer Access before it can be used.

For the TheFaithApp mobile SDKs, use **Add Flutter app** or **Add React Native
app** in Developer Access so you only enter the package name. The dashboard
creates the exact callback URL expected by the SDK.

Flutter:

```dart theme={null}
final auth = TheFaithAppAuth(apiKey: 'your-public-client-key');
```

For the full package setup and API request example, follow the
[Flutter SDK Quickstart](/api-reference/flutter-sdk).

React Native and Expo:

```tsx theme={null}
const auth = new TheFaithAppAuth({ apiKey: 'your-public-client-key' })
```

Follow the [React Native SDK Quickstart](/api-reference/react-native-sdk) for
the config plugin, native build, and API request example.

> [!NOTE]
>
> A mobile callback is handled by the installed app. Mobile developers do not need to host a separate website just to receive the authorization code.

## Required PKCE

Every hosted sign-in must use PKCE with `S256`. Generate a new verifier and challenge for each attempt:

```json theme={null}
{
  "client_key": "your-public-client-key",
  "redirect_uri": "mychurch://auth/callback",
  "state": "replace-with-random-state",
  "code_challenge": "base64url-sha256-code-verifier",
  "code_challenge_method": "S256"
}
```

Then include the matching `code_verifier` during token exchange:

```json theme={null}
{
  "client_key": "your-public-client-key",
  "code": "one-time-code",
  "redirect_uri": "mychurch://auth/callback",
  "code_verifier": "original-random-code-verifier"
}
```

The verifier must be 43–128 RFC 7636 unreserved characters. Never send it in the browser URL or reuse it for another attempt.

## Logout

To invalidate a member token, call `POST /v1/auth/logout` with the same API key and bearer token:

```bash theme={null}
curl -X POST https://api.thefaithapp.com/v1/auth/logout \
  -H "X-API-Key: your-public-client-key" \
  -H "Authorization: Bearer member-bearer-token" \
  -H "Accept: application/json"
```

## Common Errors

| Status | When it happens | How to fix it |
| - | - | - |
| `400` | The client key, Redirect URL, or one-time code is not accepted. | Confirm the configured values or start a fresh sign-in without relying on the response to reveal which value was wrong. |
| `422` | A required request field is missing or invalid. | Check `client_key`, `redirect_uri`, `state`, `code`, and required PKCE fields. |
| `401` | A protected API request has a missing or invalid bearer token. | Exchange the hosted auth code and use the returned member token. |

## Endpoint Reference

Open the `Hosted Auth` section in the API Reference navigation for the live
request builder, complete schemas, and generated examples for each auth route.


# API Introduction
Source: https://docs.thefaithapp.com/api-reference/introduction

Integrate member sign-in, church content, engagement, giving, events, and analytics through the stable v1 partner API.

# TheFaithApp Partner API

TheFaithApp `v1` is the supported API for third-party web and mobile apps. It lets an integration sign in members through hosted auth and work with the member's church-scoped content and workflows.

## Base URL

```text theme={null}
https://api.thefaithapp.com
```

All request and response bodies use JSON unless an endpoint explicitly documents a file response, such as a CSV export.

## Authentication at a glance

Protected requests require two credentials:

```http theme={null}
X-API-Key: your-public-client-key
Authorization: Bearer your-member-access-token
```

* The public client key identifies the partner app and church; it is not an authentication secret.
* The bearer token identifies the signed-in member.
* The member token must belong to the same church as the public client key.

The hosted-auth setup and code-exchange endpoints do not use these headers. They accept the client key in the request so a member can sign in before an access token exists.

> **[Make your first request](/api-reference/quickstart)**
>
> Complete hosted sign-in and load the current member.

> **[Understand hosted auth](/api-reference/hosted-auth)**
>
> Learn redirects, state validation, PKCE, token storage, and logout.

> **[Build with Flutter](/api-reference/flutter-sdk)**
>
> Add member sign-in and authenticated API requests to an Android or iOS app.

> **[Build with React Native](/api-reference/react-native-sdk)**
>
> Add hosted sign-in to an Expo or React Native app.

> **[Add giving in Flutter](/api-reference/flutter-giving-sdk)**
>
> Render authenticated general and campaign giving in a Flutter app.

> **[Add giving in React Native](/api-reference/react-native-giving-sdk)**
>
> Render authenticated general and campaign giving in React Native or Expo.

## What you can build

* Personalized church home experiences
* Audio and video sermon libraries, transcripts, chapters, and insights
* Devotionals, live streams, favorites, and bookmarks
* Church discovery and public church profiles
* Event registration and volunteer workflows
* Member campus and ministry connections, community groups, and group resources
* Shared-resource lending and mutual-aid needs and offers
* Member notifications and bulletins
* Hosted church giving experiences
* Prayer request submission
* Confidential, member-owned Pastoral Care requests and follow-up preferences
* Product and notification analytics

Chat and messaging routes are not part of this partner reference.

## Church images

Church directory and profile image URLs resolve to a bundled PNG placeholder
when the church has not uploaded a logo. Render the returned URL as-is rather
than adding a storage or CDN prefix. A custom logo replaces the placeholder
in subsequent responses. Where an endpoint returns both `image` and
`image_url`, `image` is the nullable stored upload path and `image_url` is the
display URL.

## Context headers

Some content changes with the member's local date or timezone:

| Header | Use |
| - | - |
| `X-Client-Date` | Resolve date-sensitive content such as devotionals. Use `YYYY-MM-DD`. |
| `X-Client-Timezone` | Resolve time-sensitive home content in an IANA timezone such as `Africa/Kampala`. |

## Request safety

Use an idempotency strategy in your own application for user actions. A network retry can otherwise submit the same logical action more than once when an endpoint does not expose an idempotency key.

Keep API keys and member tokens out of browser logs, analytics payloads, crash reports, source control, and public screenshots.

## Versioning

The version is part of every endpoint path. Backward-compatible fields may be added to `v1` responses over time, so clients should ignore fields they do not recognize. A breaking contract change requires a new API version.


# Pagination and Errors
Source: https://docs.thefaithapp.com/api-reference/pagination-and-errors

Handle paginated collections, validation failures, authorization errors, and safe retries.

# Response conventions

The API uses a small number of response shapes. Always branch on the HTTP status code first, then inspect the JSON body for endpoint-specific details.

## Status envelopes

Many member-scoped endpoints return:

```json theme={null}
{
  "status": "Success",
  "data": {}
}
```

Some endpoints use a boolean success field:

```json theme={null}
{
  "success": true,
  "data": {}
}
```

Treat both shapes as endpoint contracts; do not assume every endpoint uses the same top-level field names.

## Pagination

Collection endpoints generally accept `page` and `per_page`. `per_page` is capped by the endpoint, commonly at 100.

Laravel-style collection responses include the records in `data` plus pagination metadata:

```json theme={null}
{
  "current_page": 1,
  "data": [],
  "last_page": 1,
  "per_page": 20,
  "total": 0,
  "next_page_url": null,
  "prev_page_url": null
}
```

Some endpoints wrap that paginator inside a success envelope:

```json theme={null}
{
  "status": "Success",
  "data": {
    "current_page": 1,
    "data": [],
    "per_page": 20,
    "total": 0
  }
}
```

Follow the schema on each endpoint page and stop when `next_page_url` is `null` or `current_page` equals `last_page`.

## Error bodies

Depending on the endpoint, the human-readable message can appear in `message`, `error`, or `error_message`:

```json theme={null}
{
  "status": "Error",
  "message": "Validation failed",
  "errors": {
    "amount": ["The amount field is required."]
  }
}
```

Use the field-specific `errors` object to guide form corrections. Do not show raw server error details to end users.

## Common status codes

| Status | Meaning | Recommended handling |
| - | - | - |
| `400` | The request conflicts with the resource's current state. | Correct the action or refresh the resource before retrying. |
| `401` | API key or bearer token is missing, invalid, expired, or mismatched. | Re-authenticate the member and verify both credentials belong to the same church. |
| `403` | A permission, resource context, or church plan prevents the action. | Inspect the error code and plan metadata before asking an administrator to review access. |
| `404` | The resource does not exist in the authenticated church. | Refresh local state and stop retrying the same identifier. |
| `422` | One or more inputs failed validation. | Display safe field-level validation messages. |
| `429` | The rate limit was exceeded. | Back off and retry after the server's retry window. |
| `500` | An unexpected server error occurred. | Retry read-only requests with bounded exponential backoff; avoid automatically repeating mutations. |

## Plan access denials

Protected `v1` requests require the church's plan to include **Platform
Integrations**, even when the API key and member token are valid. A plan-related
`403` includes `error_code: "plan_product_unavailable"` and `plan_access` metadata.
For example, these fields identify a plan restriction:

```json theme={null}
{
  "success": false,
  "error_code": "plan_product_unavailable",
  "plan_access": {
    "product": "platform_integrations",
    "current_plan": "standard",
    "recommended_plan": "large"
  }
}
```

Ask the church's authorized administrator to review the plan and product access.
Signing the member in again, rotating credentials, or automatically retrying the
same request will not change that entitlement. For other `403` responses, review
the endpoint's permission and resource-context requirements.

## Retry guidance

* Retry `429` and transient `5xx` responses with exponential backoff and jitter.
* Cap retry attempts and set request timeouts.
* Retry safe reads automatically only when your product can tolerate stale or delayed data.
* Do not automatically retry registration, signup, or other mutations unless your application can prove the first request did not succeed.
* Log a request correlation identifier if one is returned, but never log API keys, member tokens, or personal response bodies.


# Pastoral Care Integration
Source: https://docs.thefaithapp.com/api-reference/pastoral-care

Build a confidential, member-owned Pastoral Care experience with the public v1 API.

## Build Pastoral Care into your app

The Pastoral Care API gives a signed-in member the same confidential workflows
available in TheFaithApp mobile app:

* Share, review, edit, and withdraw a care request.
* See member-safe status, visit, support-plan, and timeline information.
* Manage consent for private follow-up.
* Save or pause a private life-moment date.
* Create a quiet-day window for sensitive seasons.

> [!WARNING]
>
> Pastoral Care carries sensitive personal information. Never send request
> details, private dates, contact values, quiet-day reasons, or member guidance
> to analytics, crash reporting, application logs, push-notification payloads,
> or AI services.

## Authentication

Every Pastoral Care call requires the partner app key and the signed-in
member's access token:

```http theme={null}
X-API-Key: your-client-api-key
Authorization: Bearer your-member-access-token
Accept: application/json
Content-Type: application/json
```

The app key and member token must resolve to the same church. A mismatch returns
`401 Unauthorized`.

Follow the [Hosted Auth guide](/api-reference/hosted-auth) before integrating
these endpoints.

## Published endpoints

The public contract mirrors the Pastoral Care calls used by TheFaithApp mobile
app.

| Member action | Endpoint |
| - | - |
| Load requests and form options | `GET /v1/care-requests` |
| Share a request | `POST /v1/care-requests` |
| Edit an open request | `PUT /v1/care-requests/{careRequest}` |
| Withdraw an open request | `POST /v1/care-requests/{careRequest}/withdraw` |
| Load preferences, private dates, and quiet days | `GET /v1/care-life-moments` |
| Update consent and contact preferences | `PUT /v1/care-life-moments/preferences` |
| Add a private date | `POST /v1/care-life-moments/moments` |
| Update or pause a private date | `PUT /v1/care-life-moments/moments/{careLifeMoment}` |
| Permanently remove a private date | `DELETE /v1/care-life-moments/moments/{careLifeMoment}` |
| Add a quiet day | `POST /v1/care-life-moments/suppressions` |
| Update or deactivate a quiet day | `PUT /v1/care-life-moments/suppressions/{careCommunicationSuppression}` |
| Permanently remove a quiet day | `DELETE /v1/care-life-moments/suppressions/{careCommunicationSuppression}` |

Staff notes, staff tasks, resolution notes, Care Radar review signals, coverage
rotations, availability, rite runsheets, preaching plans, and staff
coordination are not public partner endpoints.

## Recommended app flow

**1. Load the member's care home**

Call `GET /v1/care-requests`. Keep the returned `options` with the screen;
they are the allowed values for care type, privacy, urgency, and contact
method.

The list contains active and past requests. Use `can_edit` and
`can_withdraw` to decide which actions to display.

**2. Let the member review the privacy boundary**

Explain `care_team` and `pastoral_only` before submission. Counseling,
benevolence, and crisis requests are always restricted to pastoral staff, even
if the app sends `care_team`.

**3. Collect explicit contact consent**

Send `contact_consent: true` only after the member actively confirms that
the church care team may contact them.

For phone, text, or email contact, `contact_value` may be omitted when the
signed-in member profile already has the matching value.

**4. Handle urgent requests responsibly**

For `urgency: "urgent"` or `type: "crisis_support"`, show a clear notice that
Pastoral Care is not an emergency service. Submit `emergency_acknowledged:
      true` only after the member confirms the notice.

**5. Refresh after a mutation**

Use the care request returned by create, update, or withdraw immediately,
then refresh `GET /v1/care-requests` when the screen resumes or receives a
generic care-status notification.

## Share a care request

```bash theme={null}
curl -X POST https://api.thefaithapp.com/v1/care-requests \
  -H "X-API-Key: your-client-api-key" \
  -H "Authorization: Bearer your-member-access-token" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "hospital_visit",
    "privacy": "care_team",
    "urgency": "soon",
    "details": "Please arrange a hospital visit later this week.",
    "contact_preference": "phone",
    "contact_consent": true
  }'
```

A successful create returns `201 Created` and the new record in
`data.care_request`.

### Care types

Use the values returned in `data.options.types`. The current values are:

| Value | Member-facing meaning |
| - | - |
| `general_care` | General care |
| `hospital_visit` | Hospital visit |
| `home_visit` | Home visit |
| `new_baby_support` | New-baby support |
| `counseling` | Counseling |
| `benevolence` | Benevolence |
| `grief_support` | Grief support |
| `illness_support` | Illness support |
| `crisis_support` | Crisis support |
| `pastoral_follow_up` | Pastoral follow-up |
| `wedding_preparation` | Wedding preparation |
| `baby_dedication` | Baby dedication |
| `funeral_support` | Funeral support |
| `relocation_support` | Relocation support |
| `pastoral_recommendation` | Pastoral recommendation |

## Render a request safely

Each care request can include:

* `status`, `urgency`, and whether a caregiver is assigned.
* `next_follow_up_at` when the care team has scheduled a follow-up.
* Member-visible visit times, location, instructions, and outcome.
* Member-visible support-plan dates, coordinator, and requested support.
* A reduced timeline of safe workflow events.
* `content_purged` when confidential content has reached the end of retention.

The response intentionally omits staff notes, staff tasks, internal review
activity, coverage handoffs, and private resolution summaries.

> [!NOTE]
>
> There is no public single-request `GET` endpoint. Keep the selected item from
> `GET /v1/care-requests`, and refresh the list when current data is needed.

## Edit and withdraw

`PUT /v1/care-requests/{careRequest}` is a full form update. Send all required
request fields, not only the changed field.

Use `POST /v1/care-requests/{careRequest}/withdraw` only after a confirmation
step. Withdrawal is final. The response sets `can_edit` and `can_withdraw` to
`false`.

Resolved, withdrawn, and retention-purged requests cannot be edited.

## Member-controlled follow-up

Call `GET /v1/care-life-moments` to load:

* `preferences`: current consent and contact choices.
* `life_moments`: private dates owned by the member.
* `suppressions`: the member's quiet-day windows.
* `options`: the supported enum values for your controls.

All reminder and Care Radar consent starts disabled.

### Update preferences

Preference updates are partial. Send only the settings the member changed:

```bash theme={null}
curl -X PUT https://api.thefaithapp.com/v1/care-life-moments/preferences \
  -H "X-API-Key: your-client-api-key" \
  -H "Authorization: Bearer your-member-access-token" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -d '{
    "reminders_enabled": true,
    "grief_follow_up_enabled": true,
    "hard_anniversary_follow_up_enabled": true,
    "contact_preference": "text",
    "acknowledgment_style": "ask_first"
  }'
```

Enabling a specific kind does not bypass the master `reminders_enabled`
setting. Care Radar participation and Community Group participation follow-up
also require their own separate member choices.

### Save a private life moment

```bash theme={null}
curl -X POST https://api.thefaithapp.com/v1/care-life-moments/moments \
  -H "X-API-Key: your-client-api-key" \
  -H "Authorization: Bearer your-member-access-token" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -d '{
    "kind": "grief_anniversary",
    "status": "active",
    "title": "Remember Mum",
    "event_date": "2026-09-14",
    "recurrence": "yearly",
    "reminder_lead_days": 7,
    "member_note": "Please ask before calling."
  }'
```

One-time dates must be today or later. Yearly dates can retain an earlier
calendar year because the next reminder is calculated from the next
anniversary.

Set `status: "paused"` to keep the private date without creating pending
follow-up. `DELETE` permanently removes the date and its pending reminders.

### Create a quiet day

```bash theme={null}
curl -X POST https://api.thefaithapp.com/v1/care-life-moments/suppressions \
  -H "X-API-Key: your-client-api-key" \
  -H "Authorization: Bearer your-member-access-token" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -d '{
    "topic": "all_celebrations",
    "starts_on": "2026-09-01",
    "ends_on": "2026-09-30",
    "pastoral_acknowledgment": true,
    "reason": "A sensitive family season.",
    "member_guidance": "A private text from a pastor is welcome."
  }'
```

New quiet days are active by default. The end date must be on or after the
start date. Setting `active: false` keeps the preference for later reuse;
deleting it removes the record permanently.

## Error handling

| Status | Meaning for Pastoral Care |
| - | - |
| `401` | API key or member token is missing, invalid, expired, or belongs to another church. |
| `404` | The resource does not exist or is not owned by the signed-in member. |
| `422` | Required values, consent, date rules, enum values, or emergency acknowledgment failed validation. |
| `429` | The partner API rate limit was reached. Honor `Retry-After` and retry with backoff. |

Treat `404` as a final resource miss. Do not reveal whether the identifier
belongs to another member or church.

Display validation messages beside their matching fields, but keep raw request
payloads out of logs and support diagnostics.

## Integration checklist

* Use hosted member sign-in and keep both credentials in secure storage.
* Build controls from the returned option arrays instead of hard-coding them.
* Require explicit contact consent.
* Show the non-emergency notice for urgent and crisis requests.
* Use `can_edit` and `can_withdraw` from the API response.
* Do not add Pastoral Care payloads to offline caches or analytics.
* Clear sensitive view state when the member signs out or changes church.
* Use generic push-notification copy and fetch current data after the member
  opens the app.
* Test with two members and two churches to verify ownership boundaries.

> **[List care requests](/api-reference/endpoints/pastoral-care/list-my-care-requests)**
>
> Review the complete response contract and try the request.

> **[Load care preferences](/api-reference/endpoints/pastoral-care/get-pastoral-care-preferences)**
>
> See private dates, quiet days, and supported option values.


# Platform Access and Webhooks
Source: https://docs.thefaithapp.com/api-reference/platform-access-and-webhooks

Store member-owned access preferences and verify signed outgoing event deliveries.

## Member Access Profile

Use `GET /v1/platform/access-profile` to load the authenticated member's
display, language, bandwidth, and accessibility-support preferences. Use
`PUT /v1/platform/access-profile` to update them. Both calls require the
church API key and the member bearer token, and both are bound to the same
church tenant.

Support details remain private from church staff unless
`share_with_support_team` is `true`. A request with `request_support: true` is
rejected unless the member has enabled sharing in that request or previously.

The response also describes supported church languages and offline
capabilities. Treat that list as runtime capability information rather than a
promise that every piece of content has already been downloaded.

## Outgoing Webhook Events

Church administrators configure outgoing HTTPS endpoints in the dashboard.
An endpoint subscribes to one or more of these event families:

* Event created, updated, published, or deleted
* Event registration created, updated, checked in, or canceled
* Giving record created, updated, settled, refunded, or disputed
* New members, visitors, prayer-request metadata, and form-submission metadata
* Serving assignment accepted or declined
* Safe test delivery

For scoped Zapier and Make connections, polling, and repeat-safe actions, see
[Automations](/api-reference/automation).

Giving webhook payloads intentionally omit donor identity and confidential
member narratives. Endpoint URLs cannot contain credentials, target localhost,
or resolve to a private or reserved network address; redirects are not
followed during delivery.

## Verify a Delivery

Every request contains:

| Header | Meaning |
| - | - |
| `X-TheFaithApp-Event` | Event type, such as `event.updated` |
| `X-TheFaithApp-Event-Id` | Stable delivery event UUID used across retries |
| `X-TheFaithApp-Timestamp` | Unix timestamp used when signing |
| `X-TheFaithApp-Signature` | `v1=` followed by the hexadecimal HMAC |

Build the signed message as the timestamp, a period, and the exact raw request
body:

```text theme={null}
{timestamp}.{raw_body}
```

Calculate HMAC-SHA256 with the endpoint signing secret and compare it to the
hexadecimal value after `v1=` using a timing-safe comparison. Reject stale
timestamps according to your replay window, and store processed event IDs so a
retry cannot apply the same business change twice.

Return any `2xx` status only after the receiver has durably accepted the
event. Failed deliveries use bounded automatic retries, and an administrator
can also request a manual retry with the same event ID.

To practice verification, persistent acceptance, and duplicate handling without
an account or a production delivery, copy the
[local Node.js receiver example](/api-reference/webhook-receiver-example).
It includes fictional events and runnable tests.

> [!WARNING]
>
> The signing secret is shown only at endpoint creation or rotation. Store it
> in the receiver's secret manager. Rotating it immediately invalidates the
> previous signature key.


# Quickstart
Source: https://docs.thefaithapp.com/api-reference/quickstart

Sign in a member and make your first authenticated TheFaithApp API request.

# Make your first request

This quickstart uses hosted auth to obtain a member token, then calls `GET /v1/user` with both required credentials.

## Before you begin

Confirm that the church's plan includes **Platform Integrations**. Hosted sign-in
does not grant that product access. If the first protected request returns `403`
with `error_code: "plan_product_unavailable"`, follow the
[plan access guidance](/api-reference/pagination-and-errors#plan-access-denials).

In `Settings > Developer Access` in the TheFaithApp dashboard:

1. Copy your public client key.
2. Add the exact callback URL that will receive the member after sign-in.

For local development, save a dedicated callback such as `http://localhost:3000/auth/callback`. Production and local callback URLs must each be added explicitly.

**1. Create a hosted sign-in URL**

Generate a cryptographically random `state` and a 43–128 character PKCE verifier. Send the verifier's base64url-encoded SHA-256 challenge with your callback URL.

```bash theme={null}
curl -X POST https://api.thefaithapp.com/v1/auth/start \
  -H "Content-Type: application/json" \
  -d '{
    "client_key": "your-public-client-key",
    "redirect_uri": "https://example.com/auth/callback",
    "state": "replace-with-at-least-16-random-characters",
    "code_challenge": "base64url-sha256-of-your-code-verifier",
    "code_challenge_method": "S256"
  }'
```

The response includes `auth_url`. Open it in the system browser or a browser-based mobile auth session.

**2. Validate the callback**

After sign-in, the member returns to your callback URL:

```text theme={null}
https://example.com/auth/callback?code=one-time-code&state=replace-with-a-random-value
```

Reject the callback if `state` does not exactly match the value stored when sign-in began. Exchange `code` immediately; it is short-lived and single-use.

**3. Exchange the code**

```bash theme={null}
curl -X POST https://api.thefaithapp.com/v1/auth/token \
  -H "Content-Type: application/json" \
  -d '{
    "client_key": "your-public-client-key",
    "code": "one-time-code",
    "redirect_uri": "https://example.com/auth/callback",
    "code_verifier": "your-original-43-to-128-character-verifier"
  }'
```

Store the returned `access_token` in secure server-side storage, an HTTP-only secure session cookie, Keychain, or Keystore.

**4. Load the member**

```bash theme={null}
curl https://api.thefaithapp.com/v1/user \
  -H "X-API-Key: your-public-client-key" \
  -H "Authorization: Bearer your-member-access-token" \
  -H "Accept: application/json"
```

A successful response contains `status: "Success"` and the member record in `data`.

## JavaScript example

```javascript theme={null}
const response = await fetch('https://api.thefaithapp.com/v1/user', {
  headers: {
    Accept: 'application/json',
    'X-API-Key': process.env.THEFAITHAPP_CLIENT_KEY,
    Authorization: `Bearer ${memberAccessToken}`,
  },
});

if (!response.ok) {
  const error = await response.json();
  throw new Error(error.message ?? error.error_message ?? 'TheFaithApp request failed');
}

const { data: member } = await response.json();
```

> [!WARNING]
>
> The client key is a public church-app identifier, not an authentication secret. Keep member access tokens out of source code and store them in a secure server-side session, Keychain, or Keystore.

## Next steps

* Building with Flutter? Follow the [Flutter SDK Quickstart](/api-reference/flutter-sdk).
* Building with React Native or Expo? Follow the [React Native SDK Quickstart](/api-reference/react-native-sdk).
* Adding in-app giving to Flutter? Follow the [Flutter Giving SDK](/api-reference/flutter-giving-sdk).
* Adding in-app giving to React Native or Expo? Follow the [React Native Giving SDK](/api-reference/react-native-giving-sdk).
* Read the [Hosted Auth Guide](/api-reference/hosted-auth) before implementing production sign-in.
* Review [Pagination and Errors](/api-reference/pagination-and-errors) for resilient response handling.
* Open an endpoint in the reference to see generated cURL, JavaScript, and Python examples.


# React Native Giving SDK
Source: https://docs.thefaithapp.com/api-reference/react-native-giving-sdk

Add authenticated general and campaign giving with Stripe, PayPal, and Flutterwave to a React Native or Expo app.

# Add giving to a React Native app

The `@thefaithapp/giving-react-native` package renders general and campaign
giving inside a React Native or Expo app. It uses the member session from
`@thefaithapp/auth-react-native`, presents the church's active payment
provider, and waits for TheFaithApp to confirm the payment.

The package includes:

* general giving with funds, currency, frequency, memo, and fee coverage
* campaign giving with configured donor form fields
* Stripe PaymentSheet
* hosted PayPal and Flutterwave checkout
* checkout cancellation and expiry handling
* headless checkout and custom payment-handler support

> [!NOTE]
>
> TheFaithApp creates and verifies each checkout and processes provider webhooks.
> Do not add payment-provider secret keys or webhook secrets to your mobile app.

## Before you begin

You need:

* an Expo SDK 57 or compatible React Native app
* `@thefaithapp/auth-react-native` configured with a client API key
* a signed-in TheFaithApp member
* an active payment provider configured for the church
* a native development or standalone build

Follow the [React Native SDK Quickstart](/api-reference/react-native-sdk) first
if member sign-in is not working yet.

**1. Install the packages**

Install the auth and giving SDKs:

```bash theme={null}
npm install @thefaithapp/auth-react-native@^0.1.1 @thefaithapp/giving-react-native@^0.2.1
```

Add the native payment dependencies with Expo-compatible versions:

```bash theme={null}
npx expo install @stripe/stripe-react-native react-native-webview
npx expo install expo-application expo-crypto expo-secure-store expo-web-browser
npx expo install expo-build-properties
```

**2. Configure the native plugins**

Add an application scheme, the auth plugin, and the Stripe plugin to
`app.json`:

```json theme={null}
{
  "expo": {
    "scheme": "your-church",
    "plugins": [
      "@thefaithapp/auth-react-native",
      [
        "@stripe/stripe-react-native",
        {
          "merchantIdentifier": "merchant.com.example.church",
          "enableGooglePay": false
        }
      ],
      "expo-secure-store",
      "expo-web-browser",
      [
        "expo-build-properties",
        {
          "ios": { "enableSceneSupport": true },
          "android": {
            "enableMinifyInReleaseBuilds": true,
            "enableShrinkResourcesInReleaseBuilds": true,
            "extraProguardRules": "-dontwarn com.stripe.android.pushProvisioning.**"
          }
        }
      ]
    ],
    "ios": {
      "bundleIdentifier": "com.example.church"
    },
    "android": {
      "package": "com.example.church"
    }
  }
}
```

Rebuild the native application after changing plugins:

```bash theme={null}
npx expo run:ios
# or
npx expo run:android
```

Stripe PaymentSheet cannot run in Expo Go.
Scene support is required for the example's Xcode 27 / iOS 27 setup.
The Android rule covers Stripe's optional card-issuing references while
keeping R8 and resource shrinking enabled. Giving uses PaymentSheet and
does not require card issuing.

**3. Create the authenticated giving client**

Reuse the auth instance that signs the member in:

```tsx theme={null}
import { TheFaithAppAuth } from '@thefaithapp/auth-react-native'
import {
  TheFaithAppGiving,
  createStripeGivingPaymentHandler,
} from '@thefaithapp/giving-react-native'

const auth = new TheFaithAppAuth({
  apiKey: process.env.EXPO_PUBLIC_THEFAITHAPP_API_KEY!,
})

const giving = new TheFaithAppGiving({
  auth,
  paymentHandlers: [
    createStripeGivingPaymentHandler({
      urlScheme: 'your-church',
      returnUrl: 'your-church://stripe-redirect',
    }),
  ],
})
```

The Stripe override adds the return URL used by redirect and 3DS flows. Its
provider ID replaces the built-in Stripe handler while PayPal and
Flutterwave continue to use their built-in handlers.

Before showing protected giving:

```tsx theme={null}
const session = (await auth.currentSession()) ?? (await auth.signIn())
console.log(`Giving as ${session.member.name}`)
```

The giving client does not accept a member ID or church/client ID. The
authenticated session supplies that identity on every request.

**4. Render general giving**

Add the built-in general giving view to a screen:

```tsx theme={null}
import { GeneralGivingView } from '@thefaithapp/giving-react-native'

export function GivingScreen() {
  return (
    <GeneralGivingView
      giving={giving}
      onCompleted={(result) => {
        // result.state is succeeded, pending, failed, or cancelled.
      }}
      onError={(error) => {
        // Show a safe message without logging checkout data.
      }}
    />
  )
}
```

The view loads the church's giving settings and funds. It shows only the
currencies, recurrence options, memo, and fee coverage allowed by that
configuration.

**5. Render campaign giving**

Your app chooses the campaign, then passes its numeric ID to the view:

```tsx theme={null}
import { CampaignGivingView } from '@thefaithapp/giving-react-native'

export function CampaignScreen({
  campaignId,
}: {
  campaignId: number
}) {
  return (
    <CampaignGivingView
      campaignId={campaignId}
      giving={giving}
      onCompleted={(result) => {
        // Handle succeeded, pending, failed, or cancelled.
      }}
    />
  )
}
```

If the campaign has donor fields, the package renders and validates its
text, multiline text, number, email, telephone, select, radio, checkbox,
and date fields.

Campaign discovery and selection belong to your app. The package begins
with the campaign ID you provide.

## Handle access failures

The error categories and fields below are available in
[`@thefaithapp/giving-react-native` 0.2.0](https://www.npmjs.com/package/@thefaithapp/giving-react-native/v/0.2.0).

A valid sign-in does not guarantee that the church's plan includes SDK access.
Handle `GivingError.code` according to the failure:

| Code | Meaning | Next step |
| - | - | - |
| `not_authenticated` | No usable member session, or HTTP 401 | Follow your app's sign-in recovery path. |
| `plan_access_denied` | HTTP 403 with a recognized plan denial | Ask the church administrator to review plan access. Signing in again does not change the plan. |
| `forbidden` | Another HTTP 403 permission denial | Check the permitted resource/action with the church; do not assume the member needs to sign in again. |

`statusCode` retains the HTTP status. `serverErrorCode` retains a valid bounded
machine code, including `plan_product_unavailable` or
`plan_entitlement_required`. For those plan denials, optional `planAccess`
contains only typed identifiers: `type`, `product` or `entitlement`,
`currentPlan`, and `recommendedPlan`. Missing or malformed context is omitted;
it does not prevent recognizing a plan denial. No raw response or credentials
are retained in these fields.

When upgrading from 0.1.0, add the new cases to exhaustive
`GivingErrorCode` handlers. The built-in view reports the error through
`onError` and displays its message; it does not sign the member out.

Use the giving dependency `^0.2.1` and auth `^0.1.1`.
Decoded API errors with HTTP 403 previously mapped to
`not_authenticated`. Update exhaustive switches and handler records for
`plan_access_denied` and `forbidden`, and keep sign-in recovery for missing
sessions and HTTP 401. Hand-built checkout objects and fixtures must include
`paypalSubscriptionId: null` when no PayPal subscription ID is available.

## Payment-provider behavior

The package uses the church's active/default provider. An app does not choose
between Stripe, PayPal, and Flutterwave for an individual gift.

| Provider | Experience |
| - | - |
| Stripe | Native PaymentSheet |
| PayPal | Hosted approval in an in-app WebView |
| Flutterwave | Hosted checkout in an in-app WebView |

The result from a native sheet or WebView is not treated as proof of payment.
The SDK checks TheFaithApp's webhook-backed status before reporting the final
state. A `pending` result means the provider or webhook is still processing.

Recurring options also depend on the provider account's capabilities.
Flutterwave recurring giving requires approval for automated tokenized card
charges; ordinary card acceptance alone does not establish that capability.

## Campaign fields

The built-in campaign view loads the campaign definition and submits its form
responses with the authenticated checkout. Required fields are validated
before the payment experience opens.

Both giving views accept partial `strings` overrides,
`contentContainerStyle`, `allowRecurring`, and `showMemo`.

For PayPal, recurring checkout creates a seller-scoped Partner Subscription.
The hosted approval result carries `paypal_subscription_id`; the package sends
that ID only to TheFaithApp's verification endpoint and never treats the
redirect itself as proof of payment.

## Headless checkout

The rendered views are optional. A custom form can create an authenticated
checkout and render the shared payment host:

```tsx theme={null}
const checkout = await giving.createGeneralCheckout({
  allocations: [{ amount: 25, fundId: 4 }],
  currency: 'USD',
  frequency: 'one_time',
})

<GivingPaymentHandlerHost
  giving={giving}
  checkout={checkout}
  onComplete={setResult}
  onError={setError}
/>
```

For a campaign, call `createCampaignCheckout(campaignId, request)` and include
the campaign's configured values in `request.formFields`.

Keep the host mounted until the provider completes. If your custom UI
dismisses an unrendered checkout, report it:

```tsx theme={null}
await giving.abandonCheckout(checkout)
```

## Add another payment provider

Register a handler whose `provider` matches the value configured on
TheFaithApp:

```tsx theme={null}
import type {
  GivingPaymentHandler,
  GivingPaymentHandlerProps,
} from '@thefaithapp/giving-react-native'

function ChurchPay({
  checkout,
  onComplete,
  onError,
}: GivingPaymentHandlerProps) {
  // Present the provider UI and confirm authoritative checkout status.
  return null
}

const churchPayHandler: GivingPaymentHandler = {
  provider: 'church-pay',
  Component: ChurchPay,
}

const giving = new TheFaithAppGiving({
  auth,
  paymentHandlers: [churchPayHandler],
})
```

A handler receives only one checkout's ephemeral session and narrow completion
capabilities. It does not receive the auth client, client API key, bearer
token, member ID, or church ID.

Never persist or log checkout provider data. A custom handler must complete
with the same donation ID and provider it received.

## Cancellation and cleanup

Closing a payment experience triggers a best-effort checkout abandonment
request. If the device is offline or the app terminates before that request
arrives, TheFaithApp expires the checkout on the server. A late valid webhook
still has a short grace period so a completed payment is not incorrectly
cancelled.

## Troubleshooting

| Problem | What to check |
| - | - |
| Giving says it is unavailable | Confirm the church has an active/default payment provider and supported giving configuration. |
| The member is not authenticated | Restore or create the auth session before rendering the giving view. |
| Stripe does not open | Use a native development build, rebuild after adding the plugin, and confirm the Stripe return scheme. |
| The app does not return after 3DS | Confirm `returnUrl` uses the scheme registered in `app.json`. |
| A campaign cannot be loaded | Confirm the campaign ID belongs to the signed-in member's church and the campaign is available. |
| A required campaign field is missing | Render the campaign returned by the package instead of maintaining a separate field definition. |
| A payment remains pending | Keep the status message visible; TheFaithApp updates the donation when the provider webhook arrives. |

## Package resources

* [Package on npm](https://www.npmjs.com/package/@thefaithapp/giving-react-native)
* [Source and standalone example](https://github.com/thefaithapp/thefaithapp-giving-react-native)


# React Native SDK Quickstart
Source: https://docs.thefaithapp.com/api-reference/react-native-sdk

Set up hosted member sign-in in a React Native or Expo app, register native callbacks, restore sessions, and make authenticated TheFaithApp v1 API requests.

# Use the API from React Native

The `@thefaithapp/auth-react-native` package signs a member in through
TheFaithApp and sends authenticated `v1` API requests from React Native and
Expo apps. Your app does not need to host a callback website.

## Before you begin

You need:

* an Expo SDK 57 app targeting iOS or Android
* its Android application ID and iOS bundle ID
* a client API key from `Settings > Developer Access`

**1. Add the package**

Install the SDK and its Expo modules:

```bash theme={null}
npm install @thefaithapp/auth-react-native
npx expo install expo-application expo-crypto expo-secure-store expo-web-browser
```

**2. Add the config plugin**

Add the SDK plugin and your application identifiers to `app.json`:

```json theme={null}
{
  "expo": {
    "plugins": ["@thefaithapp/auth-react-native"],
    "ios": {
      "bundleIdentifier": "com.example.app"
    },
    "android": {
      "package": "com.example.app"
    }
  }
}
```

The plugin adds the mobile callback to both native projects when you build
the app.

**3. Register your React Native app**

In the TheFaithApp dashboard:

1. Open `Settings > Developer Access`.
2. Click **Add React Native app**.
3. Append `.thefaithapp` to your application ID.
4. Add the app and copy your client API key.

For an application ID of `com.example.app`, enter:

```text theme={null}
com.example.app.thefaithapp
```

The dashboard creates the callback expected by the package:

```text theme={null}
com.example.app.thefaithapp://auth/callback
```

If iOS and Android use different identifiers, register both callbacks.
Avoid underscores because they cannot be used in a callback URI scheme.

**4. Create a native build**

Rebuild the app so the native callback configuration is included:

```bash theme={null}
npx expo run:ios
# or
npx expo run:android
```

Use a development build or standalone app for this flow. Expo Go cannot be
rebuilt with your application's callback scheme.

**5. Initialize the SDK**

Provide the client key when creating `TheFaithAppAuth`:

```tsx theme={null}
import { TheFaithAppAuth } from '@thefaithapp/auth-react-native'

const auth = new TheFaithAppAuth({
  apiKey: process.env.EXPO_PUBLIC_THEFAITHAPP_API_KEY!,
})
```

Supply the value from your development or build environment instead of
committing it to source control.

**6. Sign in a member**

Start sign-in from a button or another user action:

```tsx theme={null}
const session = await auth.signIn()
console.log(session.member.name)
```

The package returns to the app after hosted sign-in and stores the member
session securely.

**7. Call a v1 endpoint**

Use `authorizedFetch` for protected API requests:

```tsx theme={null}
const response = await auth.authorizedFetch('/v1/user')
const body = await response.json()

if (!response.ok) {
  throw new Error(body.message ?? 'The request failed.')
}
```

Pass another relative `/v1/...` path to call endpoints from the API
Reference.

## Restore the saved session

Check for a saved session when the app starts:

```tsx theme={null}
const session = await auth.currentSession()

if (session) {
  console.log(`Welcome back, ${session.member.name}`)
}
```

## Access the bearer token

When an integration needs the token directly:

```tsx theme={null}
const token = await auth.accessToken()
```

Do not log the token or include it in analytics and crash reports.

## Sign out

Revoke the member session and remove its saved copy:

```tsx theme={null}
await auth.signOut()
```

## Handle SDK errors

```tsx theme={null}
import { TheFaithAuthError } from '@thefaithapp/auth-react-native'

try {
  await auth.signIn()
} catch (error) {
  if (error instanceof TheFaithAuthError && error.code === 'cancelled') {
    // The member closed the sign-in session.
  }
}
```

## Troubleshooting

| Problem | What to check |
| - | - |
| The redirect is rejected | Confirm the value added with **Add React Native app** matches the application ID with `.thefaithapp` appended. |
| The app does not reopen after sign-in | Rebuild the native app after adding the config plugin and confirm the installed application ID. |
| Sign-in does not return while using Expo Go | Create an Expo development build or standalone app. |
| A protected request says the member is not authenticated | Call `signIn()` or restore a saved session before sending the request. |

## Next steps

* Add authenticated general and campaign giving with the
  [React Native Giving SDK](/api-reference/react-native-giving-sdk).
* Browse the endpoint groups in the API Reference navigation.
* Read [Pagination and Errors](/api-reference/pagination-and-errors) before
  loading lists or adding retry behavior.
* Use the public
  [standalone sample](https://github.com/thefaithapp/thefaithapp-auth-react-native/tree/main/example)
  as a compact reference implementation.


# Volunteer Serving API
Source: https://docs.thefaithapp.com/api-reference/volunteer-serving

Integrate the first-party volunteer schedule, team, wellbeing, training, and worship-planning contracts.

## Contracts

Volunteer Serving uses two authenticated contracts:

* Staff administration endpoints under `/api/volunteer-serving` require an
  authenticated administrator and the permission listed for the action.
* Member endpoints under `/v2/volunteer` require the signed-in member's bearer
  token and always resolve records inside that member's church.

These endpoints power TheFaithApp's web dashboard and Flutter app. Existing
partner apps should continue using the published v1 Volunteer Opportunity
endpoints unless first-party Volunteer Hub access has been agreed for that app.

## Staff Permissions

| Permission | Scope |
| - | - |
| `volunteer_schedule` | Roles, teams, templates, plans, assignments, swaps, standby alerts, attendance, feedback, and recognition |
| `volunteer_sensitive` | Eligibility, clearances, training records, restricted wellbeing signals, and private leader notes |
| `worship_planning` | Songs, arrangements, preparation assets, run-of-show items, and CCLI reports |

An administrator may have more than one permission. Read responses omit
sensitive fields unless the token has `volunteer_sensitive`.

## Staff Endpoints

| Action | Endpoint |
| - | - |
| Load the workspace and form options | `GET /api/volunteer-serving/overview`, `GET /api/volunteer-serving/options` |
| Create or update a role | `POST /api/volunteer-serving/roles`, `PUT /api/volunteer-serving/roles/{uuid}` |
| Add or update a team member | `POST /api/volunteer-serving/memberships`, `PUT /api/volunteer-serving/memberships/{uuid}` |
| Review a restricted volunteer profile | `PUT /api/volunteer-serving/profiles/{memberId}` |
| Create or generate from a template | `POST /api/volunteer-serving/templates`, `POST /api/volunteer-serving/templates/{uuid}/generate` |
| Create, update, publish, or duplicate a plan | `POST /api/volunteer-serving/plans`, `PUT /api/volunteer-serving/plans/{uuid}`, `POST /api/volunteer-serving/plans/{uuid}/publish`, `POST /api/volunteer-serving/plans/{uuid}/duplicate` |
| Create or update an assignment | `POST /api/volunteer-serving/plans/{planUuid}/assignments`, `PUT /api/volunteer-serving/assignments/{uuid}` |
| Review a swap or contact standby volunteers | `PUT /api/volunteer-serving/swaps/{uuid}`, `POST /api/volunteer-serving/assignments/{uuid}/standby` |
| Record leader feedback or recognition | `POST /api/volunteer-serving/assignments/{uuid}/leader-feedback`, `POST /api/volunteer-serving/recognition` |
| Manage training | `POST /api/volunteer-serving/training/requirements`, `PUT /api/volunteer-serving/training/records/{uuid}` |
| Manage the run of show | `POST /api/volunteer-serving/plans/{planUuid}/items`, `PUT /api/volunteer-serving/plan-items/{uuid}`, `PUT /api/volunteer-serving/plans/{planUuid}/items/reorder`, `DELETE /api/volunteer-serving/plan-items/{uuid}` |
| Manage songs and preparation files | `POST /api/volunteer-serving/songs`, `POST /api/volunteer-serving/songs/{songUuid}/arrangements`, `POST /api/volunteer-serving/songs/{songUuid}/assets` |
| Generate a song usage report | `GET /api/volunteer-serving/reports/ccli` |

Publishing a plan changes named draft assignments to `invited` and empty
assignments to `unfilled`. When coverage or eligibility warnings exist, the
request must explicitly send `confirm_warnings: true` after a human review.
Safety-clearance failures cannot be overridden.

## Member Endpoints

| Member action | Endpoint |
| - | - |
| Load the complete Volunteer Hub | `GET /v2/volunteer/hub` |
| Update reminders, load, rest, recognition, or conduct | `PUT /v2/volunteer/profile` |
| Add/remove weekly availability | `POST /v2/volunteer/availability`, `DELETE /v2/volunteer/availability/{uuid}` |
| Add/remove a blockout | `POST /v2/volunteer/blockouts`, `DELETE /v2/volunteer/blockouts/{uuid}` |
| Confirm or decline | `POST /v2/volunteer/assignments/{uuid}/respond` |
| Request a swap | `POST /v2/volunteer/assignments/{uuid}/swap` |
| Send private wellbeing feedback | `POST /v2/volunteer/assignments/{uuid}/feedback` |
| Check in | `POST /v2/volunteer/assignments/{uuid}/check-in` |
| Claim an open role | `POST /v2/volunteer/assignments/{uuid}/claim` |
| Invalidate and replace the private calendar link | `POST /v2/volunteer/calendar/rotate` |

The hub response includes the member's own profile, team memberships,
availability, blockouts, assignments, eligible open roles, active Volunteer
Opportunities, training records, and opted-in recognition. It excludes private
leader notes, eligibility notes, clearance values, health flags, and another
member's schedule.

## Calendar Feed

`GET /api/public/volunteer/calendar/{token}.ics` returns the member's published
serving commitments as iCalendar data. Treat the random token as a secret:
never log it, include it in analytics, or place it in a public page. A call to
`POST /v2/volunteer/calendar/rotate` immediately invalidates the old
URL and returns a profile containing the replacement URL.

## Reminder Delivery

The scheduled `volunteers:send-reminders` workflow creates idempotent assignment
and training reminders. It respects quiet hours, category/channel preferences,
and active email or confirmed SMS consent before dispatching through existing
communication providers.


# Local Webhook Receiver Example
Source: https://docs.thefaithapp.com/api-reference/webhook-receiver-example

Copy a dependency-free Node.js receiver and test signed, repeat-safe acceptance with fictional events.

Practice the [signed webhook contract](/api-reference/platform-access-and-webhooks#verify-a-delivery)
without creating an endpoint or sending a production delivery. This example
verifies exact raw bytes, saves the complete event before responding, and
recognizes a retry after a restart.

## Run locally

Use Node.js 22 or later on macOS or Linux with a local filesystem that supports
file and directory sync. Create an empty folder and copy all three files below
into it using their displayed names. No package installation is needed.

```sh theme={null}
node --test receiver.test.mjs
export TFA_WEBHOOK_SECRET="$(node -e 'process.stdout.write(require("node:crypto").randomBytes(32).toString("hex"))')"
node receiver.mjs
```

In a second terminal, set the same **local** secret in
`TFA_WEBHOOK_SECRET` and run `node fixture.mjs`. The sender only contacts
`http://127.0.0.1:8787/webhooks/thefaithapp`. First delivery returns
`202 {"accepted":true,"duplicate":false}`. Repeat it to receive
`200 {"accepted":true,"duplicate":true}`. Stop and restart the receiver in
the same folder, then repeat the fixture to check that the saved event is
recognized. Inspect `inbox/` to see the complete fictional event.

> [!NOTE]
>
> This loopback HTTP URL is for the local fixture only. It cannot be registered
> as a TheFaithApp endpoint. A real endpoint must use publicly reachable HTTPS.

## What acceptance means

The receiver signs nothing itself: it calculates the expected HMAC-SHA256 over
the timestamp, a period, and the exact incoming bytes, then compares with
`timingSafeEqual`. Header event ID and type must match the signed body.
Each fixture retry has a fresh timestamp and the same event ID and body.

A single process serializes acceptance, writes a restricted-permission file,
syncs it, renames it into the inbox and syncs the directory before returning
`202`. An identical saved event returns `200` after its file and directory
are synced again. Changed signed content with the same ID returns `409`;
storage failure returns `503` so the sender can retry. The five-minute
timestamp window and 1 MiB body limit are example policies, not TheFaithApp
server settings. Keep the receiver clock synchronized.

The tests cover signatures, changed raw bytes, stale and future timestamps,
missing/repeated headers, malformed JSON, envelope mismatch, storage failure,
concurrent duplicate requests, restart persistence, and waiting for acceptance
before acknowledging. The fictional Unicode/slash vector was cross-checked
against the PHP sender's JSON flags and HMAC calculation.

## Example files

```javascript receiver.mjs theme={null}
import { createHmac, timingSafeEqual } from 'node:crypto';
import { mkdir, open, readFile, rename, rm } from 'node:fs/promises';
import { createServer } from 'node:http';
import { dirname, join, resolve } from 'node:path';
import { pathToFileURL } from 'node:url';

const uuid = /^[0-9a-f]{8}-[0-9a-f]{4}-[1-8][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i;
const eventType = /^[a-z][a-z0-9]*(?:[._][a-z0-9]+)*$/;
const jsonType = /^application\/json(?:\s*;\s*charset=utf-8)?$/i;

export class Rejected extends Error {
  constructor(status, message) { super(message); this.status = status; }
}

function header(request, name) {
  const values = [];
  for (let i = 0; i < request.rawHeaders.length; i += 2) {
    if (request.rawHeaders[i].toLowerCase() === name) values.push(request.rawHeaders[i + 1]);
  }
  if (values.length !== 1) throw new Rejected(400, 'Missing or repeated header');
  return values[0];
}

export function verify(request, rawBody, secret, now = Math.floor(Date.now() / 1000)) {
  const timestamp = header(request, 'x-thefaithapp-timestamp');
  const signature = header(request, 'x-thefaithapp-signature');
  const id = header(request, 'x-thefaithapp-event-id');
  const type = header(request, 'x-thefaithapp-event');
  if (!/^(0|[1-9][0-9]{0,12})$/.test(timestamp) || !/^v1=[0-9a-f]{64}$/.test(signature)
      || !uuid.test(id) || !eventType.test(type)) throw new Rejected(400, 'Malformed signing headers');
  // Five minutes is this example's policy, not a server-enforced contract.
  if (Math.abs(now - Number(timestamp)) > 300) throw new Rejected(401, 'Timestamp outside replay window');
  const expected = createHmac('sha256', secret).update(timestamp + '.').update(rawBody).digest();
  if (!timingSafeEqual(expected, Buffer.from(signature.slice(3), 'hex'))) {
    throw new Rejected(401, 'Invalid signature');
  }
  let payload;
  try { payload = JSON.parse(new TextDecoder('utf-8', { fatal: true }).decode(rawBody)); }
  catch { throw new Rejected(400, 'Invalid UTF-8 JSON'); }
  if (!payload || Array.isArray(payload) || payload.id !== id || payload.type !== type
      || typeof payload.created_at !== 'string' || !Number.isFinite(Date.parse(payload.created_at))
      || !payload.data || typeof payload.data !== 'object') {
    throw new Rejected(400, 'Invalid event envelope');
  }
  return { id: id.toLowerCase(), type, rawBody: rawBody.toString('utf8') };
}

async function syncDirectory(directory) {
  const handle = await open(directory, 'r');
  try { await handle.sync(); } finally { await handle.close(); }
}

// One process per inbox. This queue also serializes overlapping HTTP retries.
export async function createInbox(directory) {
  directory = resolve(directory);
  try { await mkdir(directory, { mode: 0o700 }); }
  catch (error) { if (error.code !== 'EEXIST') throw error; }
  await syncDirectory(dirname(directory));
  let queue = Promise.resolve();
  return {
    accept(event) {
      const result = queue.then(async () => {
        const target = join(directory, event.id + '.json');
        let previous, exists = false;
        try { previous = JSON.parse(await readFile(target, 'utf8')); exists = true; }
        catch (error) { if (error.code !== 'ENOENT') throw error; }
        if (exists) {
          if (!previous || previous.id !== event.id || previous.type !== event.type || previous.rawBody !== event.rawBody) {
            throw new Rejected(409, 'Event ID already has different content');
          }
          // Also sync retries: the earlier attempt may have failed after rename.
          const existing = await open(target, 'r');
          try { await existing.sync(); } finally { await existing.close(); }
          await syncDirectory(directory);
          return false;
        }
        const temporary = join(directory, '.' + event.id + '.' + process.pid + '.tmp');
        // A stale temporary file from a terminated process is never an accepted event.
        await rm(temporary, { force: true });
        const file = await open(temporary, 'wx', 0o600);
        try {
          await file.writeFile(JSON.stringify(event) + '\n');
          await file.sync();
        } finally { await file.close(); }
        await rename(temporary, target);
        await syncDirectory(directory);
        return true;
      });
      queue = result.catch(() => {}); // One failed write must not block later retries.
      return result;
    },
  };
}

function readBody(request, limit) {
  return new Promise((resolveBody, reject) => {
    const chunks = [];
    let size = 0;
    let oversized = false;
    request.on('data', chunk => {
      size += chunk.length;
      if (size > limit) {
        if (!oversized) reject(new Rejected(413, 'Body too large'));
        oversized = true;
        chunks.length = 0;
      } else if (!oversized) chunks.push(chunk);
    });
    request.on('end', () => { if (!oversized) resolveBody(Buffer.concat(chunks)); });
    request.on('error', reject);
    request.on('aborted', () => reject(new Rejected(400, 'Incomplete request')));
  });
}

export function createReceiver({ secret, inbox, now, bodyLimit = 1024 * 1024 }) {
  if (!secret) throw new Error('A signing secret is required');
  const server = createServer(async (request, response) => {
    let status, result;
    try {
      if (request.url !== '/webhooks/thefaithapp') throw new Rejected(404, 'Not found');
      if (request.method !== 'POST') {
        response.setHeader('Allow', 'POST');
        throw new Rejected(405, 'Use POST');
      }
      if (!jsonType.test(header(request, 'content-type'))) throw new Rejected(415, 'Use application/json');
      const event = verify(request, await readBody(request, bodyLimit), secret, now?.());
      const inserted = await inbox.accept(event);
      status = inserted ? 202 : 200;
      result = { accepted: true, duplicate: !inserted };
    } catch (error) {
      status = error instanceof Rejected ? error.status : 503;
      result = { error: error instanceof Rejected ? error.message : 'Inbox unavailable; retry later' };
    }
    // No request bodies, signing secrets, or internal filesystem errors are logged.
    response.writeHead(status, { 'Content-Type': 'application/json', 'Connection': 'close' });
    response.end(JSON.stringify(result));
  });
  server.requestTimeout = 10_000;
  server.headersTimeout = 10_000;
  return server;
}

if (process.argv[1] && import.meta.url === pathToFileURL(resolve(process.argv[1])).href) {
  try {
    const inbox = await createInbox(resolve('inbox'));
    const server = createReceiver({ secret: process.env.TFA_WEBHOOK_SECRET, inbox });
    server.listen(8787, '127.0.0.1', () => console.log('Local receiver: http://127.0.0.1:8787/webhooks/thefaithapp'));
    server.on('error', () => { console.error('Could not start local receiver'); process.exitCode = 1; });
  } catch {
    console.error('Could not initialize receiver; check TFA_WEBHOOK_SECRET and local inbox storage');
    process.exitCode = 1;
  }
}
```

```javascript fixture.mjs theme={null}
import { createHmac } from 'node:crypto';
import { resolve } from 'node:path';
import { pathToFileURL } from 'node:url';

// Fictional data only. The raw string deliberately contains Unicode and a slash.
export const fixtureBody = '{"id":"02fdcf7e-822d-4ce8-b35e-cb9f28ad56d2","type":"platform.test","created_at":"2026-10-16T09:00:00.000000Z","data":{"message":"Fictional café / test"}}';
export const fixtureSecret = 'whsec_fictional_example_only_never_use_in_production';
export const fixtureTimestamp = '1792141200';

export function signedHeaders(body, secret, timestamp = String(Math.floor(Date.now() / 1000))) {
  const { id, type } = JSON.parse(body);
  return {
    'Content-Type': 'application/json',
    'X-TheFaithApp-Event': type,
    'X-TheFaithApp-Event-Id': id,
    'X-TheFaithApp-Timestamp': timestamp,
    'X-TheFaithApp-Signature': 'v1=' + createHmac('sha256', secret).update(timestamp + '.').update(body).digest('hex'),
  };
}

if (process.argv[1] && import.meta.url === pathToFileURL(resolve(process.argv[1])).href) {
  if (!process.env.TFA_WEBHOOK_SECRET) throw new Error('Set the same local TFA_WEBHOOK_SECRET as the receiver');
  // Fixed loopback destination: this helper cannot send to a production endpoint.
  const response = await fetch('http://127.0.0.1:8787/webhooks/thefaithapp', {
    method: 'POST', headers: signedHeaders(fixtureBody, process.env.TFA_WEBHOOK_SECRET), body: fixtureBody,
  });
  console.log(response.status, await response.text());
  if (!response.ok) process.exitCode = 1;
}
```

> **receiver.test.mjs — copy this file to run the tests**
>
> ```javascript receiver.test.mjs theme={null}
> import assert from 'node:assert/strict';
> import { createHmac } from 'node:crypto';
> import { request } from 'node:http';
> import { mkdtemp, readdir, readFile, rm, writeFile } from 'node:fs/promises';
> import { tmpdir } from 'node:os';
> import { join } from 'node:path';
> import test from 'node:test';
> import { createInbox, createReceiver, verify } from './receiver.mjs';
> import { fixtureBody, fixtureSecret, fixtureTimestamp, signedHeaders } from './fixture.mjs';
>
> const now = Number(fixtureTimestamp);
> const fixtureId = JSON.parse(fixtureBody).id;
> const headers = () => signedHeaders(fixtureBody, fixtureSecret, fixtureTimestamp);
> const rawRequest = values => ({ rawHeaders: Object.entries(values).flat() });
> const signedAnyBody = body => ({ ...headers(), 'X-TheFaithApp-Signature': 'v1=' +
>   createHmac('sha256', fixtureSecret).update(fixtureTimestamp + '.').update(body).digest('hex') });
> const verifyBody = (body = fixtureBody, values = headers(), time = now) =>
>   verify(rawRequest(values), Buffer.from(body), fixtureSecret, time);
>
> async function harness(t, options = {}) {
>   const root = await mkdtemp(join(tmpdir(), 'tfa-webhook-example-'));
>   const directory = join(root, 'inbox');
>   const inbox = await createInbox(directory);
>   const server = createReceiver({ secret: fixtureSecret, inbox, now: () => now, ...options });
>   await new Promise(resolve => server.listen(0, '127.0.0.1', resolve));
>   t.after(async () => {
>     server.closeAllConnections();
>     await new Promise(resolve => server.close(resolve));
>     await rm(root, { recursive: true, force: true });
>   });
>   async function send(body = fixtureBody, values = headers(), { method = 'POST', path = '/webhooks/thefaithapp' } = {}) {
>     return new Promise((resolve, reject) => {
>       const wireHeaders = Array.isArray(values) ? [...values, 'Host', '127.0.0.1', 'Content-Length', String(Buffer.byteLength(body))] : values;
>       const req = request({ hostname: '127.0.0.1', port: server.address().port, path, method, headers: wireHeaders }, response => {
>         let text = '';
>         response.setEncoding('utf8').on('data', chunk => { text += chunk; });
>         response.on('end', () => resolve({ status: response.statusCode, body: JSON.parse(text) }));
>       });
>       req.on('error', reject);
>       req.end(body);
>     });
>   }
>   return { directory, inbox, send };
> }
>
> test('fixed PHP-compatible Unicode/slash signing vector and exact bytes', () => {
>   assert.equal(headers()['X-TheFaithApp-Signature'], 'v1=dd29fa30b814fa96065cefd2b31c27bf4a643d770a609416e4ee905d5368a8a9');
>   assert.equal(verifyBody().rawBody, fixtureBody);
>   assert.throws(() => verifyBody(fixtureBody + '\n'), /Invalid signature/);
>   assert.throws(() => verifyBody(fixtureBody.replace('café', 'cafe')), /Invalid signature/);
> });
>
> test('missing, repeated and malformed signing headers are rejected', () => {
>   for (const name of ['X-TheFaithApp-Event', 'X-TheFaithApp-Event-Id', 'X-TheFaithApp-Timestamp', 'X-TheFaithApp-Signature']) {
>     const missing = headers(); delete missing[name];
>     assert.throws(() => verifyBody(fixtureBody, missing), /Missing or repeated/);
>     const repeated = rawRequest(headers()); repeated.rawHeaders.push(name.toLowerCase(), headers()[name]);
>     assert.throws(() => verify(repeated, Buffer.from(fixtureBody), fixtureSecret, now), /Missing or repeated/);
>   }
>   for (const [name, value] of [
>     ['X-TheFaithApp-Signature', 'v1=00'], ['X-TheFaithApp-Signature', 'v2=' + '0'.repeat(64)],
>     ['X-TheFaithApp-Timestamp', '1e9'], ['X-TheFaithApp-Timestamp', '+' + fixtureTimestamp],
>     ['X-TheFaithApp-Event-Id', '../escape'], ['X-TheFaithApp-Event', 'Event Updated'],
>   ]) assert.throws(() => verifyBody(fixtureBody, { ...headers(), [name]: value }), /Malformed/);
> });
>
> test('five-minute replay policy rejects stale and future timestamps, including on duplicates', async t => {
>   assert.equal(verifyBody(fixtureBody, headers(), now + 300).id, fixtureId);
>   for (const time of [now + 301, now - 301]) assert.throws(() => verifyBody(fixtureBody, headers(), time), /replay window/);
>   let clock = now;
>   const { send } = await harness(t, { now: () => clock });
>   assert.equal((await send()).status, 202);
>   clock += 301;
>   assert.equal((await send()).status, 401);
>   assert.equal((await send(fixtureBody, signedHeaders(fixtureBody, fixtureSecret, String(clock)))).status, 200);
> });
>
> test('verified JSON must have a matching envelope; no reserialization before HMAC', () => {
>   for (const payload of [null, [], {}, { ...JSON.parse(fixtureBody), data: null },
>     { ...JSON.parse(fixtureBody), created_at: 'invalid' }]) {
>     const body = JSON.stringify(payload);
>     assert.throws(() => verifyBody(body, signedAnyBody(body)), /Invalid event envelope/);
>   }
>   for (const body of [Buffer.from('{truncated'), Buffer.from([0xff])]) {
>     assert.throws(() => verifyBody(body, signedAnyBody(body)), /Invalid UTF-8 JSON/);
>   }
>   const body = fixtureBody.replace(fixtureId, '12fdcf7e-822d-4ce8-b35e-cb9f28ad56d2');
>   const values = signedHeaders(body, fixtureSecret, fixtureTimestamp);
>   values['X-TheFaithApp-Event-Id'] = fixtureId;
>   assert.throws(() => verifyBody(body, values), /Invalid event envelope/);
>   const pretty = JSON.stringify(JSON.parse(fixtureBody), null, 2);
>   assert.equal(verifyBody(pretty, signedHeaders(pretty, fixtureSecret, fixtureTimestamp)).rawBody, pretty);
> });
>
> test('accepted event is complete on disk; repeat and fresh-timestamp retry survive restart', async t => {
>   const { directory, send } = await harness(t);
>   assert.deepEqual(await send(), { status: 202, body: { accepted: true, duplicate: false } });
>   assert.deepEqual(JSON.parse(await readFile(join(directory, fixtureId + '.json'), 'utf8')), verifyBody());
>   assert.deepEqual(await send(), { status: 200, body: { accepted: true, duplicate: true } });
>   // Constructing a new store has no in-memory seen-ID cache.
>   assert.equal(await (await createInbox(directory)).accept(verifyBody()), false);
>   assert.equal((await readdir(directory)).filter(name => name.endsWith('.json')).length, 1);
> });
>
> test('twenty simultaneous duplicate requests produce one accepted inbox record', async t => {
>   const { directory, send } = await harness(t);
>   const results = await Promise.all(Array.from({ length: 20 }, () => send()));
>   assert.equal(results.filter(result => result.status === 202).length, 1);
>   assert.equal(results.filter(result => result.status === 200).length, 19);
>   assert.deepEqual(await readdir(directory), [fixtureId + '.json']);
> });
>
> test('same event ID with changed signed content is a conflict and cannot overwrite the first event', async t => {
>   const { directory, send } = await harness(t);
>   await send();
>   const changed = fixtureBody.replace('Fictional', 'Changed');
>   assert.equal((await send(changed, signedHeaders(changed, fixtureSecret, fixtureTimestamp))).status, 409);
>   assert.equal(JSON.parse(await readFile(join(directory, fixtureId + '.json'), 'utf8')).rawBody, fixtureBody);
> });
>
> test('storage failure returns non-2xx; retry can recover without a poisoned queue', async t => {
>   const { directory, send } = await harness(t);
>   await rm(directory, { recursive: true });
>   assert.deepEqual(await send(), { status: 503, body: { error: 'Inbox unavailable; retry later' } });
>   await createInbox(directory);
>   assert.equal((await send()).status, 202);
> });
>
> test('corrupt saved event fails closed; no overwrite or successful acknowledgement', async t => {
>   const { directory, send } = await harness(t);
>   const target = join(directory, fixtureId + '.json');
>   await writeFile(target, '{truncated');
>   assert.equal((await send()).status, 503);
>   assert.equal(await readFile(target, 'utf8'), '{truncated');
> });
>
> test('HTTP path, method, content type, body limit and duplicate wire headers are checked', async t => {
>   const { send } = await harness(t);
>   assert.equal((await send('', headers(), { path: '/different' })).status, 404);
>   assert.equal((await send('', headers(), { method: 'GET' })).status, 405);
>   assert.equal((await send(fixtureBody, { ...headers(), 'Content-Type': 'text/plain' })).status, 415);
>   assert.equal((await send(fixtureBody, [...Object.entries(headers()), ['x-thefaithapp-event-id', fixtureId]].flat())).status, 400);
>   const limited = await harness(t, { bodyLimit: 8 });
>   assert.equal((await limited.send()).status, 413);
> });
>
> test('no 2xx before the inbox finishes durable acceptance', async t => {
>   let release;
>   const persisted = new Promise(resolve => { release = resolve; });
>   let reached;
>   const started = new Promise(resolve => { reached = resolve; });
>   const { send } = await harness(t, { inbox: { async accept() { reached(); await persisted; return true; } } });
>   let returned = false;
>   const response = send().then(value => { returned = true; return value; });
>   await started;
>   assert.equal(returned, false);
>   release();
>   assert.equal((await response).status, 202);
> });
> ```

## Before adapting this for production

Run **one process per inbox**. This sample has no distributed lock, business
worker or database transaction. It accepts events into storage; it does not
apply business changes or guarantee exactly-once business processing. For a
production service, use a transactional inbox/queue and an idempotent worker,
HTTPS ingress, a secret manager, monitoring and a retention policy.

Keep accepted records throughout your retry horizon: deleting the inbox also
deletes deduplication history. Test persistence on your actual storage. If file
or directory sync fails, the example fails rather than acknowledging unsynced
data. Use only fictional data locally; the included fixed test secret is not
a production credential. The example logs neither request bodies nor secrets.

See [Node's file sync](https://nodejs.org/api/fs.html#filehandlesync) and
[raw HTTP headers](https://nodejs.org/api/http.html#messagerawheaders)
references for the underlying Node APIs.


# App customization is now available
Source: https://docs.thefaithapp.com/changelog/2026-05-15-app-customization-is-now-available

Design and publish your church's mobile app experience with themes, navigation, custom pages, reusable content blocks, and phone and tablet previews.

# App customization is now available

*May 15, 2026*

[Back to changelog](/changelog/index)

Church teams can now shape a more branded mobile app experience inside TheFaithApp. App Customization brings your theme, navigation, custom pages, reusable content blocks, preview tools, and release controls into one workflow.

![Page builder workspace](https://mintcdn.com/thefaithltd/q9MkJNOGHbY9afCq/images/product/settings-branding-customization/page-builder.png?fit=max\&auto=format\&n=q9MkJNOGHbY9afCq\&q=85\&s=4c255a2bc288284995927a3b3ca50ca2)

## What's New

* Choose your app colors, typography style, corner radius, and theme behavior from `Brand & Theme`.
* Build a custom navigation experience for the tabs members see in the mobile app.
* Create custom pages with text, images, buttons, cards, sections, and reusable content blocks.
* Reuse content carousels across multiple pages from the component library.
* Preview your work in phone and tablet layouts before publishing.
* Publish releases when you are ready, then decide whether the live app should use the latest custom design.

## Why It Matters

App Customization gives churches more control over how their mobile experience looks and feels without requiring a full rebuild for every change. Teams can prepare updates in stages, review them, and publish when they are ready.

## Where You'll Use It

* `Settings > Branding` still manages white-label branding, domains, and public-page styling.
* `App Customization > Brand & Theme` controls the visual foundation for the mobile experience.
* `App Customization > Navigation` manages app tabs and destinations.
* `App Customization > Page Builder` is where custom pages are created and updated.
* `App Customization > Component Library` stores reusable blocks you can place across pages.
* `App Customization > Releases` is where teams publish a live version and turn `Use custom design` on or off.

![Customization releases](https://mintcdn.com/thefaithltd/q9MkJNOGHbY9afCq/images/product/settings-branding-customization/customization-releases.png?fit=max\&auto=format\&n=q9MkJNOGHbY9afCq\&q=85\&s=2b8ec975a9971dbe9f6ada9b734661cd)

## What Members Will Notice

When a release is live, members can see the updated navigation and custom pages directly in the mobile app. This makes it easier to tailor the app around your church's content, campaigns, and priorities.

## Learn More

Read the full setup guide in [Settings, Branding, and App Customization](/product/settings-branding-and-customization).


# App customization is now available to all admins
Source: https://docs.thefaithapp.com/changelog/2026-05-29-app-customization-is-now-available-to-all-admins

All admins can now open TheFaithApp's App Customization workspace to edit themes, navigation, custom pages, and reusable blocks without a rollout gate.

# App customization is now available to all admins

*May 29, 2026*

[Back to changelog](/changelog/index)

The App Customization workspace is now open to all admins. Teams no longer need the earlier rollout gate before opening the page builder, navigation editor, component library, and brand theme workspace.

## What's Changed

* `App Customization` now appears directly in the admin product picker.
* Admins can open the workspace without waiting for the earlier staged rollout.
* Existing customization tools, previews, and releases continue to work the same way.

## Why This Matters

Church teams can now start shaping their mobile app experience without needing a separate access step. This makes the workspace easier to discover and easier to adopt across more admins.

## Learn More

Read the full guide in [Settings, Branding, and App Customization](/product/settings-branding-and-customization).


# Sermon AI tools are now available
Source: https://docs.thefaithapp.com/changelog/2026-06-09-sermon-ai-tools-are-now-available

Generate reviewed sermon transcripts, chapters, insights, translations, quote cards, content drafts, and uploaded-video clips.

# Sermon AI tools are now available

*June 9, 2026*

[Back to changelog](/changelog/index)

Sermon AI is now available for churches using TheFaithApp. Admins can turn uploaded sermons into reviewed transcripts, member study tools, translations, shareable content, quote cards, and short video clips.

## What's New

* Generate synced transcripts for uploaded audio sermons and uploaded video sermons.
* Review, edit, publish, or unpublish transcripts before members see them.
* Create sermon chapters so members can jump to key moments.
* Generate sermon insights, including summaries, key points, scripture references, reflection questions, and discussion prompts.
* Translate reviewed transcripts into supported languages.
* Create social posts, short snippets, newsletter blurbs, and bulletin announcements from sermon content.
* Design and download quote cards from sermon excerpts.
* Suggest and render downloadable clips from uploaded video sermons.

## Why This Matters

Church teams can make sermons easier to revisit, search, translate, study, and share without asking members to pay for access. Staff stay in control because generated content can be reviewed before it is published.

## Learn More

Read the full workflow in [Content Management](/product/content-management#sermon-ai-tools).


# Chat realtime is now powered by Firebase
Source: https://docs.thefaithapp.com/changelog/2026-06-10-chat-realtime-is-now-powered-by-firebase

Firebase Realtime Database now delivers chat messages, typing indicators, and room updates across TheFaithApp's admin dashboard and mobile app.

# Chat realtime is now powered by Firebase

*June 10, 2026*

[Back to changelog](/changelog/index)

Chat now uses Firebase Realtime Database for live updates across the admin web dashboard and the mobile app. Message records still stay in TheFaithApp's database, while Firebase handles the fast room updates members expect during an active conversation.

## What's New

* New messages appear in open chat rooms without waiting for a full page refresh.
* Typing indicators update across supported chat surfaces.
* Chat participants, room access, and message activity stay in sync between web and mobile.
* The older Laravel Reverb realtime layer has been removed from chat.

## Why This Matters

Chat now feels more immediate while keeping TheFaithApp's database as the source of truth for message history, membership, moderation, and reporting.


# Chat rooms have stronger admin controls
Source: https://docs.thefaithapp.com/changelog/2026-06-11-chat-rooms-have-stronger-admin-controls

Admins can now manage room behavior with moderation, read states, mentions, reactions, and notification preferences.

# Chat rooms have stronger admin controls

*June 11, 2026*

[Back to changelog](/changelog/index)

Chat rooms now include stronger controls for keeping conversations organized, safe, and easier to follow.

## What's New

* Admins can delete inappropriate messages.
* Admins can pin or unpin important messages.
* Rooms can be locked when posting should pause.
* Members can be muted or restricted from posting when needed.
* Mentions help people call attention to specific members in group chats.
* Message reactions let members respond quickly with lightweight faith-community reactions.
* Read receipts and unread dividers make it clearer where a member left off.
* Per-room notification preferences let members mute conversations for a set time or turn off alerts for a room.

## Why This Matters

Church teams can keep group conversations healthier without losing the quick, friendly rhythm of chat.


# Sermon AI content is available in the external API
Source: https://docs.thefaithapp.com/changelog/2026-06-11-sermon-ai-content-is-available-in-the-external-api

Third-party apps can now read published sermon transcripts, chapters, and insights.

# Sermon AI content is available in the external API

*June 11, 2026*

[Back to changelog](/changelog/index)

Third-party apps using the TheFaithApp `v1` API can now read published sermon transcripts, chapter markers, and sermon insights for audio sermons and uploaded video sermons.

## What's Changed

* `GET /v1/media/{mediaId}/transcript` returns the published synced transcript, cue timestamps, available languages, and published translations.
* `GET /v1/media/{mediaId}/chapters` returns published chapter markers.
* `GET /v1/media/{mediaId}/insights` returns the published summary, key points, scripture references, reflection questions, and discussion prompts.
* Audio, video, and category media lists include `has_transcript` so apps can decide when to show transcript controls before downloading cue data.

## Why This Matters

Churches can bring reviewed sermon AI content into custom mobile apps, websites, and partner experiences while keeping unpublished drafts private.

## Learn More

Read the API reference for [sermon transcripts](/api-reference/endpoints/content/get-sermon-transcript), [sermon chapters](/api-reference/endpoints/content/get-sermon-chapters), and [sermon insights](/api-reference/endpoints/content/get-sermon-insights).


# Chat conversations are easier to follow
Source: https://docs.thefaithapp.com/changelog/2026-06-12-chat-conversations-are-easier-to-follow

Chat now has better room lists, timeline grouping, search, presence, reply navigation, and group details.

# Chat conversations are easier to follow

*June 12, 2026*

[Back to changelog](/changelog/index)

The chat experience has been polished across web and mobile so members can find the right room, catch up faster, and understand who is active.

## What's New

* Chat lists now show the latest message and unread counts.
* Messages are grouped by timeline labels such as Today, Yesterday, and older dates.
* Infinite scroll now keeps older messages in the correct order while loading more history.
* Room search helps find messages by text, sender, attachments, and sermon attachments.
* Tapping a quoted reply scrolls to the original message and highlights it.
* Group details now show members, photos, files, and shared sermons.
* Member lists support loading more members in larger rooms.
* Presence and last-seen states help show who is currently around.
* Members can open public rooms before joining, then join from inside the room when they are ready to participate.

## Why This Matters

Busy chat rooms are easier to scan, catch up on, and trust because the room state no longer feels disconnected between the list, the message feed, and the group details.


# Chat attachments, voice notes, and sermon sharing are upgraded
Source: https://docs.thefaithapp.com/changelog/2026-06-13-chat-attachments-voice-notes-and-sermon-sharing-are-upgraded

Chat now supports richer image, PDF, voice note, and sermon attachment experiences across web and mobile.

# Chat attachments, voice notes, and sermon sharing are upgraded

*June 13, 2026*

[Back to changelog](/changelog/index)

Chat attachments now feel more like a modern messaging experience, with richer previews and better playback for media shared inside a conversation.

## What's New

* Images display directly in chat bubbles and can be opened in a larger preview.
* PDF attachments can be opened from inside chat.
* Attachment handling is focused on the currently supported file types: images and PDFs.
* Upload progress gives clearer feedback while a file is being sent.
* Multiple image attachments can be viewed more naturally as a gallery.
* Members can download or share supported attachments where the app surface allows it.
* Mobile users can record and send voice notes.
* Sermons can be attached to chat messages from the sermon picker.
* Audio and video sermon cards show useful playback information and open in the appropriate in-app or browser player.
* The now-playing chat experience shows progress and lets members return to the active sermon more easily.

## Why This Matters

Members can share more than text without leaving the conversation, and sermon attachments now connect chat directly to the listening and watching experience.


# Prayer Community adds a church prayer feed
Source: https://docs.thefaithapp.com/changelog/2026-06-17-prayer-community-adds-a-church-prayer-feed

Members can now share approved prayer requests, mark that they prayed, and follow up when prayers are answered.

# Prayer Community adds a church prayer feed

*June 17, 2026*

[Back to changelog](/changelog/index)

Prayer Community adds a member-facing prayer feed for each church.

## What's New

* Members can open the Prayer Community from the Connect page.
* Members can submit prayer requests from the mobile app.
* Approved prayer requests appear in a church-scoped feed.
* Pending or rejected requests stay out of the community feed.
* Members can tap `I prayed` to show support for a request.
* `I prayed` is counted once per member for each request.
* Members can review their own submitted requests.
* Request owners can mark their own requests as answered.
* Answered requests can include optional testimony text.
* Anonymous requests hide requester identity in the feed.
* Non-anonymous requests can show the member or display name.

## Why This Matters

Prayer requests no longer stop at private submission. Churches can build a simple prayer loop where members share needs, pray together, and celebrate answered prayers while the existing approval process remains the moderation gate.


# Prayer Rooms beta is ready for mobile testing
Source: https://docs.thefaithapp.com/changelog/2026-06-17-prayer-rooms-beta-is-ready-for-mobile-testing

Members can now create and join beta audio and video prayer rooms, use room controls, and give toward room goals.

# Prayer Rooms beta is ready for mobile testing

*June 17, 2026*

[Back to changelog](/changelog/index)

Prayer Rooms are now available as a beta experience from the mobile Connect page.

## What's New

* Members can open `Connect` and enter the `Prayer Rooms` beta area.
* Hosts can create audio or video prayer rooms and move directly into the room.
* Rooms support speaker, listener, host, and moderator behavior.
* Audio rooms show connected participants, mute state, and speaking state.
* Video rooms use a compact meeting layout with participant controls.
* Hosts can end a room and remove participants from the live session.
* Rooms can be locked, scheduled, recurring, or configured with recording consent.
* Recording and prayer clip workflows support consent-aware room settings.
* Room giving can be enabled with a goal amount.
* Native room giving is used when the church has a connected payment provider.
* External giving links remain available as a fallback when native payment setup is not ready.
* The room view can show tracked giving progress for native gifts.

## Why This Matters

Prayer Rooms give churches a live ministry space for prayer, support, and hosted gatherings without requiring a separate meeting tool.

The beta label helps teams test the experience carefully while audio, video, recording, and room giving continue through final QA.


# Hosted member sign-in simplifies API access
Source: https://docs.thefaithapp.com/changelog/2026-06-19-hosted-member-sign-in-simplifies-api-access

External apps can now use TheFaithApp-hosted member sign-in, with setup docs and API reference pages for the full auth flow.

# Hosted member sign-in simplifies API access

*June 19, 2026*

[Back to changelog](/changelog/index)

External apps can now connect to TheFaithApp with a simpler hosted member sign-in flow. Churches no longer need to upload their own Firebase service account just to let members sign in from a connected app.

## What's New

* Developer Access now provides a client key for connected apps.
* Admins can add Redirect URLs for web callbacks and mobile deep links.
* Members sign in through TheFaithApp-hosted auth and return with a short-lived code.
* Connected apps exchange that code for a member bearer token before calling the `v1` API.
* The API docs now include the full hosted auth setup guide, endpoint reference, mobile redirect guidance, and PKCE examples.
* Hosted auth stays on the TheFaithApp auth host, even when a church uses a custom public domain.

## Why This Matters

Connected apps are easier to set up, and TheFaithApp can manage the member authentication flow without exposing platform Firebase credentials or requiring each church to bring its own Firebase project.


# Prayer Rooms trial limits protect live room capacity
Source: https://docs.thefaithapp.com/changelog/2026-06-22-prayer-rooms-trial-limits-protect-live-room-capacity

Trial Prayer Rooms now default to smaller gatherings with monthly participant-minute metering before upgrading.

# Prayer Rooms trial limits protect live room capacity

*June 22, 2026*

[Back to changelog](/changelog/index)

Prayer Rooms trial usage now has clearer live-room limits before a church upgrades to Prayer Rooms Plus.

## What's Changed

* Trial rooms now default to 10 participants.
* Trial usage supports one live room at a time.
* Trial usage includes 500 participant minutes per billing period.
* Larger live rooms require Prayer Rooms Plus.
* Members see a clearer upgrade message when a room reaches the trial or participant-minute limit.

## Why This Matters

These limits keep the beta useful for testing while protecting live audio and video capacity as churches begin using Prayer Rooms.


# Member Directory connects your church
Source: https://docs.thefaithapp.com/changelog/2026-06-27-member-directory-connects-your-church

Members can browse a privacy-first church directory, control what they share, and staff can manage households, approvals, and reminders.

# Member Directory connects your church

*June 27, 2026*

[Back to changelog](/changelog/index)

The Member Directory gives each church a privacy-first way for members to find and connect with one another.

## What's New

* Members can browse and search the church directory from the mobile app, and keep browsing offline from the last list they loaded.
* Member profiles show only what each person has chosen to share.
* Contact details, location, birthday, and household are private by default.
* Members control their own visibility: a master directory switch, whole-profile visibility (everyone, leaders only, or hidden), and per-field settings — reachable from both the directory and the profile page.
* Members can open a household to see a family together, and see a "Birthdays this week" view.
* Members can set a profile photo and see their household (read-only) when editing their profile.
* When a church requires approval, sensitive profile edits are submitted for staff review with a clear confirmation, while other changes save right away.
* Staff can configure the directory, manage households (adding members by searching for them by name or email), and designate directory leaders from the web dashboard.
* Staff can require approval for sensitive profile edits and review them in a change-request queue.
* Churches can opt in to a daily birthday and anniversary digest for directory leaders.
* Children are excluded from the directory by default.

## Why This Matters

Connection is hard when people can't find each other, but a directory shouldn't come at the cost of privacy. The Member Directory lets members reach the right person while staying in control of what they share — and gives staff the tools to keep households organized and sensitive changes reviewed.


# Member Connections brings campuses, ministries, and groups together
Source: https://docs.thefaithapp.com/changelog/2026-07-10-member-connections-and-community-groups

Members can manage church connections, discover community groups, and use privacy-safe directory filters.

Member Connections is now available across mobile, web, and the Member Directory.

Members can:

* Review active and pending campus, ministry, and Community Group connections.
* Request campus or ministry connections and choose directory visibility.
* Browse Community Groups and join open groups or request approval.
* Leave connections that are no longer current.
* Filter the Member Directory by campus, ministry, Community Group, and general
  location.

Staff can:

* Assign member connections and choose roles or a primary campus.
* Approve or decline connection requests.
* Configure campus and ministry approval rules.
* Create, edit, activate, and archive Community Groups.
* Publish announcements and study guides, review discussion activity, record
  attendance, and maintain leader-only notes.

Members can participate in group discussions and read shared study guides after
joining a group.

Community Groups are separate from admin Permission Groups. Directory results
use only active, approved connections that members have chosen to show, and
location filtering never exposes a private street address.


# Member data hygiene and migration tools are available
Source: https://docs.thefaithapp.com/changelog/2026-07-11-member-data-hygiene-and-migration

Review duplicate members, normalize addresses, audit consent, and map CSV imports from other church systems with TheFaithApp's data hygiene tools.

# Member data hygiene and migration tools are available

The Members workspace now includes a **Data hygiene** tab for keeping directory
records accurate and privacy-aware.

* Review duplicate records and confirm safe merges.
* Preview and apply address normalization.
* Audit missing profile fields and directory consent.
* Review accepted, failed, and skipped import rows.
* Use guided CSV column mapping for Planning Center, Breeze, Subsplash, and
  Tithe.ly exports.

Migrations use exported files rather than direct third-party account access,
and duplicate merges archive the source record instead of permanently deleting
it.


# Your church week now meets you on Home
Source: https://docs.thefaithapp.com/changelog/2026-07-14-your-church-week-now-meets-you-on-home

The mobile Home screen brings together personal commitments, useful next steps, group updates, saved sermon moments, and quick actions.

# Your church week now meets you on Home

The mobile Home screen now gives every member a clearer view of what matters to
them today.

* See your next registered event, Community Group meeting, or serving
  commitment.
* Jump to giving, prayer, event check-in, chat, or sermons from one row.
* Get one practical next-step suggestion based on your existing connections.
* Read announcements from Community Groups you have joined.
* Reopen saved sermons and personal sermon moments.
* Continue an unfinished audio sermon from the position saved on your device.
* Keep these personal sections when your church uses a published custom Home
  design.
* Read Home headings, actions, commitment context, and recommendations in your
  selected app language.
* See a calm, localized all-caught-up state when no personal commitments,
  circle updates, saved items, or listening progress need attention.

Sections appear only when they are useful, so the church's normal bulletins,
sermons, events, and devotionals remain easy to browse.


# Welcome every new visitor with one connected journey
Source: https://docs.thefaithapp.com/changelog/2026-07-16-welcome-every-new-visitor-with-one-connected-journey

Guests can plan a visit or connect without an account while staff coordinate consent-aware follow-up and useful next steps.

# Welcome every new visitor with one connected journey

Churches can now guide a guest from first interest to meaningful follow-up in
one connected workflow.

* Publish campus arrival, parking, kids, accessibility, gathering, map, image,
  and theme information on a public Plan a Visit page.
* Share direct visitor links or embed Plan a Visit and Connect Card forms in a
  church website.
* Receive anonymous guest submissions in a searchable Visitor Inbox without
  adding them to the member directory, with safe retry and spam safeguards.
* Assign owners, check in first visits, record no-shows, add private notes, and
  keep the full relationship timeline together.
* Configure consent-aware confirmations, personal welcome tasks, overdue
  reminders, pastor-call escalation, and optional newcomer-event invitations.
* Pause, resume, reassign, retry, skip, or complete follow-up steps.
* Show only next steps that lead to a campus, group, event, serving, prayer,
  visit, Connect Card, or pastor-care experience that is ready to use.
* Link or convert a visitor to a member while preserving the visitor history
  and reviewing exact Visitor or Member contact matches first; records are not
  merged automatically.
* Connect a church-owned Handwrytten account and deliberately send a
  consent-first physical welcome card with test/live warnings, reusable
  defaults, staff approval, status history, and safe failure handling.

Email, text, and phone permission remain separate throughout the journey, and
pending automated follow-up stops when a visitor is closed or converted.


# Flutter apps can plug into hosted sign-in
Source: https://docs.thefaithapp.com/changelog/2026-07-18-flutter-apps-can-plug-into-hosted-sign-in

Developers can register a Flutter app in Developer Access and use the new SDK to receive a member bearer token without hosting a callback website.

# Flutter apps can plug into hosted sign-in

Developer Access now includes **Add Flutter app**. Enter the app's package name
with `.thefaithapp` appended, and TheFaithApp creates the matching mobile
callback automatically.

The new Flutter SDK opens TheFaithApp's hosted member sign-in, returns the
member to the installed app, stores the member session securely, and provides
an authenticated client for the `v1` API. Developers provide only the client
API key.

Mobile developers no longer need to host a separate callback website just to
receive the authorization result. A standalone sample app is also available
for testing the complete sign-in and API flow on iOS and Android. The API
Reference includes a Flutter quickstart covering installation, app
registration, sign-in, authenticated requests, session restoration, and
logout.


# React Native apps can use hosted sign-in
Source: https://docs.thefaithapp.com/changelog/2026-07-18-react-native-apps-can-use-hosted-sign-in

Developers can add hosted member sign-in to React Native and Expo apps without running a callback website.

# React Native apps can use hosted sign-in

Developer Access now includes **Add React Native app**. Enter the application
ID with `.thefaithapp` appended, and TheFaithApp creates the matching mobile
callback automatically.

The React Native SDK opens hosted member sign-in, returns a bearer token, saves
the member session securely, and sends authenticated `v1` API requests. Its
Expo config plugin adds the callback to the generated iOS and Android projects.

The API Reference includes a complete React Native and Expo quickstart covering
installation, callback registration, native builds, sign-in, API requests,
session restoration, and logout.

Current-member responses now include only the public church context apps need.


# Forms connects church intake to follow-up
Source: https://docs.thefaithapp.com/changelog/2026-07-21-forms-connect-intake-to-follow-up

Churches can build, publish, share, and embed flexible forms, then assign and complete every response from one organized inbox.

# Forms Connects Church Intake to Follow-Up

**Forms** is now a top-level TheFaithApp product for collecting information and
coordinating what happens next. Churches can begin with a blank form or one of
15 church-focused templates, arrange questions in the visual builder, control
who may respond, and publish an immutable version when it is ready.

![The Forms library](https://mintcdn.com/thefaithltd/OUU7GQw1uxz3I73Y/images/product/forms/forms-library.png?fit=max\&auto=format\&n=OUU7GQw1uxz3I73Y\&q=85\&s=9dc21fbc3b06b7abe822b318292e5a76)

Share a form through its public link, a QR code, WhatsApp, the member app, or an
embed on the church website. Public pages keep the church's configured domain,
theme, schedule, access rules, and response limit. Known members can receive
safe prefills, while invite-only forms use individually tracked invitations.

Every submission arrives in the **Response Inbox**. Staff can search and filter
responses, choose visible columns, save views, assign an owner, set a priority
or due date, add private notes, and complete follow-up with a clear activity
history. Restricted and sensitive forms can be limited to named managers, and
exports apply the same access protections as the inbox.

Forms is responsive across desktop, tablet, and phone layouts. The builder,
public form, and response inbox also support keyboard navigation, dark mode,
right-to-left languages, and browser text scaling for more accessible use.

Forms also connects reviewed responses to existing church workflows such as
visitors, member journeys, events, volunteering, groups, prayer requests, and
Outreach review. These connections are deliberate actions rather than automatic
copies.

Forms remains separate from **Outreach Campaigns → Donor Forms**. Donor Forms
continues to collect campaign-specific supporter information, while the Forms
product serves broader church intake and follow-up.

Read the [Forms product guide](/product/forms) for the complete setup,
publishing, sharing, response-management, privacy, and lifecycle workflow.


# Handwrytten cards are ready for visitor follow-up
Source: https://docs.thefaithapp.com/changelog/2026-07-23-handwrytten-cards-are-ready-for-visitor-follow-up

Churches can connect Handwrytten and send consent-aware welcome cards from a visitor journey, with guarded sender setup, test or live review, and order tracking.

# Handwrytten Cards Are Ready for Visitor Follow-Up

Churches can now use their own Handwrytten account to prepare, review, send,
and track personal welcome cards from the visitor journey.

* Connect and test Handwrytten from **Settings** → **Integrations**, then see
  the account mode, available credit, card designs, handwriting styles, and
  default return address.
* If the account has no default sender, choose a saved Handwrytten address or
  add one in TheFaithApp. A clear confirmation is required before the connected
  account is changed.
* Open a visitor's **Handwrytten** tab, record postal-mail permission, choose a
  design and handwriting style, and review the recipient, message, and return
  address before submitting.
* Test orders remain clearly separated from live orders. Live approval warns
  staff that the connected Handwrytten account will be charged and the card
  will be mailed.
* Refresh submitted orders manually, review their status and provider response,
  and cancel an order when Handwrytten still allows it.
* Keep every draft, submission, status update, and failure in the visitor
  history without storing the church's payment-card details in TheFaithApp.

Handwrytten continues to own the address book, artwork, payment method,
printing, and mailing. TheFaithApp coordinates staff approval and visitor
history without silently changing the connected account.


# Pastoral prayer protects confidential care
Source: https://docs.thefaithapp.com/changelog/2026-07-23-pastoral-prayer-protects-confidential-care

Members can share an encrypted prayer request with a smaller, permission-controlled pastoral team.

# Pastoral prayer protects confidential care

*July 23, 2026*

[Back to changelog](/changelog/index)

Members can now choose `Pastoral team only` when a prayer request needs a
smaller confidentiality boundary than the general leaders-only workflow.

## What's New

* Members see a clear privacy explanation before sharing with the pastoral
  team.
* Churches can grant private pastoral prayer access separately from ordinary
  Prayer Requests access.
* Authorized caregivers can coordinate urgency and follow-up from the existing
  prayer workspace.
* The request shows a safe access history so authorized staff can understand
  when it was viewed or acted on.

## Privacy by Default

Pastoral prayer content is encrypted and stays out of Prayer Walls,
prayer-team lists and emails, Prayer Rooms, general exports, and AI tools.
Notifications use a general message without the prayer, identity, or contact
details.

Pastoral exports contain workflow metadata only. After a request is answered,
withdrawn, or rejected, the encrypted content is retained for the church's
configured period and then removed while the minimal accountability history
remains.


# Prayer requests add safer audience controls
Source: https://docs.thefaithapp.com/changelog/2026-07-23-prayer-requests-add-audience-controls

Members can share prayer requests with their church, a Community Group, or church leaders and retain control through editing and withdrawal.

# Prayer requests add safer audience controls

*July 23, 2026*

[Back to changelog](/changelog/index)

Prayer Community now gives each request an explicit audience while keeping
anonymity as a separate choice.

## What's New

* Members can choose the Church Prayer Wall, one of their active Community
  Groups, or church leaders only.
* Group requests are available only to active members of the selected group.
* Public-form requests default to church leaders only.
* Members can edit an active request. Previously approved requests return for
  staff review before appearing again.
* Members can withdraw a request without deleting the church's follow-up
  record.
* The Prayer Wall separates active requests from answered prayers.
* Staff can see and filter request audiences and review answered or withdrawn
  state.

## Why This Matters

Prayer needs do not all belong in the same room. The new controls let members
ask the right people to pray while churches retain a clear moderation and
follow-up workflow.


# Prayer teams coordinate daily care
Source: https://docs.thefaithapp.com/changelog/2026-07-23-prayer-teams-coordinate-daily-care

Churches can organize verified prayer volunteers around safe daily lists, assignments, availability, and weekly email digests.

# Prayer teams coordinate daily care

*July 23, 2026*

[Back to changelog](/changelog/index)

Prayer teams now have one shared workflow from church setup to a member's
daily prayer rhythm.

## What's New

* Staff can create prayer teams from volunteers who already passed the prayer
  support verification and safeguarding process.
* Each team supports leader, coordinator, and intercessor roles, weekly
  availability, active or paused status, and email preferences.
* Members see a focused daily list and can mark requests as praying or
  completed.
* Staff can deliberately assign an eligible request to the whole team or one
  team member.
* Active, opted-in team members receive a weekly prayer list by email.

## Privacy by Default

Automatic lists use approved church requests only. Leaders-only requests
require a staff assignment, Community Group requests stay out of team lists,
and anonymous requests remain anonymous. Team screens and emails do not expose
requester phone or email details.


# Private prayer journals build a personal prayer rhythm
Source: https://docs.thefaithapp.com/changelog/2026-07-23-private-prayer-journals-and-reminders

Members can keep prayers private, record answered reflections, share when ready, and choose daily, weekly, or one-time reminders.

# Private prayer journals build a personal prayer rhythm

*July 23, 2026*

[Back to changelog](/changelog/index)

Prayer Community now supports the personal side of prayer as well as the
shared Prayer Wall.

## What's New

* Members can record prayers in a journal that only they can access.
* Journal prayers can be marked answered with a private reflection.
* A member can copy a journal prayer into a moderated church, Community Group,
  or leaders-only request when they are ready to share.
* Daily and weekly reminders help members build a regular prayer rhythm.
* One-time reminders support private journal prayers and follow-up on requests
  the member owns or previously marked `I prayed`.
* Reminder notifications open Prayer Community without exposing a private
  journal description on the lock screen.

## Why This Matters

Not every prayer begins as something to share. Members can now keep a private
record, notice answered moments, and invite others in only when it feels
appropriate.


# Urgent prayer connects members to timely follow-up
Source: https://docs.thefaithapp.com/changelog/2026-07-23-urgent-prayer-connects-timely-follow-up

Members can privately ask leaders for timely prayer support while churches coordinate a safe, owned response.

# Urgent prayer connects members to timely follow-up

*July 23, 2026*

[Back to changelog](/changelog/index)

Members can now privately ask church leaders for urgent follow-up on an active
prayer request.

## What's New

* Members can request urgent follow-up with a short private reason and see its
  progress in `My Requests`.
* Authorized staff receive a safe alert, review the request, assign an owner,
  and track acknowledgement, active follow-up, and resolution.
* Staff can create a bounded Pastoral Care handoff when broader coordination is
  needed.
* An eligible request can open a locked Prayer Room for the member and a
  verified prayer-team leader.

## Privacy by Default

Urgency never appears as a badge on the Prayer Wall. Alerts do not contain the
prayer text, requester identity, contact details, or private reason. Care
handoffs keep only the source reference and coordination details instead of
copying sensitive request content.

Urgent follow-up is a church ministry workflow and is not an emergency service.


# Pastoral Care connects private requests to follow-up
Source: https://docs.thefaithapp.com/changelog/2026-07-24-pastoral-care-connects-private-requests-to-follow-up

Members can confidentially ask for care while authorized church staff coordinate ownership, notes, tasks, and resolution.

# Pastoral Care connects private requests to follow-up

*July 24, 2026*

[Back to changelog](/changelog/index)

Members can now open `Pastoral Care` from the mobile Connect page and share a
confidential need directly with their church.

## What's New

* Members can request general care, a hospital visit, counseling, benevolence,
  grief or illness support, crisis support, or pastoral follow-up.
* Members can choose urgency, privacy, and a preferred contact method, then
  review, edit, or withdraw an open request.
* Authorized staff have one care queue for assignment, follow-up dates,
  confidential notes, tasks, activity, and resolution.
* Prayer care handoffs can become linked care cases without copying the source
  prayer text.

## Privacy by Default

Sensitive content is encrypted, ordinary and pastoral-only cases have separate
permission boundaries, and staff access is recorded. Notifications use general
language without member identity, request text, contact details, or care notes.

After a request is resolved or withdrawn, the private content is removed at the
end of the church's configured retention period while a minimal accountability
history remains.


# Pastoral Care coordinates visits and coverage
Source: https://docs.thefaithapp.com/changelog/2026-07-24-pastoral-care-coordinates-visits-and-coverage

Care teams can schedule visits, plan response coverage, share availability, and organize new-baby support.

# Pastoral Care coordinates visits and coverage

*July 24, 2026*

[Back to changelog](/changelog/index)

Pastoral Care now carries a confidential request through practical,
team-coordinated support without creating a separate record.

## What's New

* Authorized staff can schedule and complete hospital, home, and other care
  visits inside a care request.
* A shared Coordination view brings upcoming visits, primary and backup
  response coverage, recurring caregiver availability, and simple workload
  counts together.
* New-baby requests can include a dated support plan, an assigned coordinator,
  and requested help such as meals, visits, transport, supplies, or prayer.
* Members can review their own visit schedule and safe support-plan details in
  the mobile app.

## Privacy Stays Intact

The existing church and permission boundaries apply to every coordination
view. Visit details, outcomes, support preferences, and private coordination
notes are encrypted, and member notifications do not include sensitive care
content.

Members never see staff-only support-plan or coverage notes. The retention
workflow removes private visit and support-plan content after the closed case
reaches the end of its configured retention period.


# Pastoral Care remembers member-approved moments
Source: https://docs.thefaithapp.com/changelog/2026-07-24-pastoral-care-remembers-member-approved-moments

Members can choose private follow-up dates, contact preferences, and quiet days in Pastoral Care, with reminders visible only to authorized caregivers.

# Pastoral Care remembers member-approved moments

*July 24, 2026*

[Back to changelog](/changelog/index)

Pastoral Care can now remember meaningful dates without turning private care
into public recognition.

## Member Control Comes First

* Reminders are off until a member explicitly enables them.
* Members can choose birthday, grief, illness, crisis, and hard-anniversary
  follow-up separately.
* Each private date can be one-time or yearly, paused, edited, or permanently
  removed.
* Members choose a contact method and whether a gentle message is welcome,
  staff should ask first, or the date should be remembered without contact.

## Gentler Staff Follow-Up

The staff Life moments view shows member-approved dates, due follow-ups, and
eligible caregivers. Alerts use generic language and never include the
member's identity or the private moment.

Members can also pause automated birthday, wedding-anniversary, baby/family,
or all celebration recognition during a chosen quiet-day window. Restricted
reasons and guidance remain encrypted and visible only to appropriately
authorized pastoral staff.

Wedding preparation, baby dedication, funeral support, relocation support, and
pastoral recommendation requests now use the same confidential care casework
as other Pastoral Care requests.


# Mobile giving SDKs are available for Flutter and React Native
Source: https://docs.thefaithapp.com/changelog/2026-07-25-mobile-giving-sdks-are-available

Developers can add authenticated general and campaign giving without placing payment-processing endpoints or provider secrets in their apps.

# Mobile giving SDKs are available for Flutter and React Native

The new Flutter and React Native giving SDKs let a signed-in member give from a
church app using the church's active payment provider.

Both SDKs include ready-to-use general and campaign giving views. They load the
church's funds, currency and recurrence settings, campaign donor fields, memo
and fee-coverage options, then present Stripe, PayPal, or Flutterwave.

Developers do not need to publish or call the underlying payment-processing
routes directly. The SDKs use the authenticated member session, while
TheFaithApp creates the checkout, verifies its church and member scope,
processes provider webhooks, and owns the final payment status.

Payment presentation is extensible, so another provider can be added without
rebuilding the general and campaign forms. Custom handlers receive only
checkout-scoped data and narrow completion capabilities, never member IDs,
client IDs, API keys, bearer tokens, or webhook secrets.

The API Reference now includes complete setup and integration guides for:

* [`thefaithapp_giving`](https://pub.dev/packages/thefaithapp_giving) for Flutter
* [`@thefaithapp/giving-react-native`](https://www.npmjs.com/package/@thefaithapp/giving-react-native) for React Native and Expo


# Partner apps can offer confidential Pastoral Care
Source: https://docs.thefaithapp.com/changelog/2026-07-25-partner-apps-can-offer-pastoral-care

Church apps can now add the member-owned Pastoral Care experience through the supported v1 API.

*July 25, 2026*

[Back to changelog](/changelog/index)

Third-party church apps can now offer the same member-owned Pastoral Care
experience used in TheFaithApp mobile.

## What Members Can Do

Partner apps can let a signed-in member:

* Share, review, edit, and withdraw a confidential care request.
* Choose care-team or pastoral-only visibility.
* Choose urgency and a preferred contact method.
* Review safe status, follow-up, visit, support-plan, and timeline information.
* Manage consent-based follow-up preferences.
* Save, pause, edit, or remove private life-moment dates.
* Create and manage quiet days during sensitive seasons.

## Built Around the Member Boundary

The public API returns only records owned by the signed-in member and their
church. Staff notes, tasks, resolution notes, Care Radar review, availability,
coverage, rite runsheets, preaching plans, and internal coordination remain
inside the protected staff product.

Urgent and crisis requests still require the member to acknowledge that
Pastoral Care is not an emergency service. Counseling, benevolence, and crisis
requests remain restricted to pastoral staff.

## Developer Resources

The new [Pastoral Care integration guide](/api-reference/pastoral-care)
explains authentication, screen flow, privacy boundaries, error handling, safe
data practices, and all 12 published operations. Each operation also has a
generated API reference page with request and response schemas.


# Pastoral Care adds consent-first review signals
Source: https://docs.thefaithapp.com/changelog/2026-07-25-pastoral-care-adds-consent-first-review-signals

Care teams can review supported follow-up signals without automatically labeling or contacting members.

# Pastoral Care adds consent-first review signals

*July 25, 2026*

[Back to changelog](/changelog/index)

Pastoral Care now gives authorized care teams a consent-first place to review
supported situations that may need human attention.

## Church and Member Control

Care Radar is off by default. Eligible church administrators choose whether to
enable it and set review thresholds for unowned care cases, overdue follow-ups,
and active-case capacity.

Members separately choose whether their recorded Community Group absences may
appear for review. That participation source stays off unless the member
enables both Care Radar and group participation follow-up.

## Human Review, Not Automatic Action

Authorized staff can acknowledge or dismiss a visible signal and add a minimum
encrypted note when useful. A signal never diagnoses or labels a member, sends
a message, or opens a care case automatically.

The Care Radar view also shows which potential sources are not ready. General
service attendance, guest continuity, household drift, serving
disengagement, keyword inference, and weighted caregiver scoring remain
deferred until their source data and safeguarding boundaries are reliable.


# Pastoral Care organizes rites, coverage, and preaching
Source: https://docs.thefaithapp.com/changelog/2026-07-25-pastoral-care-organizes-rites-coverage-and-preaching

Care teams can coordinate rite checklists, bounded caregiver handoffs, and dependable preaching plans.

# Pastoral Care organizes rites, coverage, and preaching

*July 25, 2026*

[Back to changelog](/changelog/index)

Pastoral Care now gives authorized staff focused sidebar workspaces for funeral
and wedding details, caregiver absences, and preaching plans. Each workspace
opens directly from the `Pastoral Care` submenu under `Church Management`, so
staff do not need to switch between unrelated tools on one page.

## Rite Runsheets

Staff can start a funeral or wedding runsheet from an existing confidential
care case. A practical checklist covers family communication, participants,
service details, venue, documents, music, and logistics. Private family and
coordination details remain encrypted.

## Bounded Caregiver Coverage

Coverage Mode snapshots a caregiver's active cases for a defined absence.
Covering staff can record minimum next actions and review activity during the
window. When coverage ends, open work is handed back for re-entry review.

## Dependable Preaching History

The preaching calendar records the actual scheduled date, speaker, audience,
service, series, Scripture, and important liturgical or civil moments. Plans
marked delivered build a reviewed Scripture ledger from launch forward rather
than treating old upload dates as preached dates.

Successor dossiers, personal-story storage, historical sermon import, and
specialized or anonymous care workflows remain deferred until their own
governance and safeguarding rules are ready.


# Discipleship turns classes into formation pathways
Source: https://docs.thefaithapp.com/changelog/2026-07-27-discipleship-turns-classes-into-formation-pathways

Churches can build formation pathways with lessons, quizzes, teachers, member progress, and verifiable completion certificates.

# Discipleship Turns Classes into Formation Pathways

**Discipleship** is now a top-level TheFaithApp product for church-owned classes
and spiritual formation. Administrators can start blank or use a membership,
baptism, new-believer, or leadership template, then customize every section and
lesson for their church.

Lessons can combine teaching, Scripture, video, audio, downloads, reflection,
group discussion, and acknowledgement prompts. Teachers can add optional or
required quizzes with single-choice, multiple-choice, true-or-false, and
short-answer questions, along with accepted answers, scoring, explanations,
passing thresholds, and attempt limits.

Discipleship managers can assign teachers and reviewers without giving every
staff member full product control. Publishing creates a fixed pathway version,
so a learner keeps the lessons they started while the church prepares a later
update.

Members can discover pathways in the mobile app, enroll in open pathways,
request approval where required, continue lessons, take quizzes, and follow
their progress through completion. Staff can approve requests, add invited
learners, and review or manage enrollment from the pathway learner dashboard.
Churches can also place Discipleship directly in their customized mobile
navigation.

Churches can enable completion certificates and customize their title, award
text, signatory, and accent color. Completing all required lessons issues a
downloadable PDF automatically. Each certificate has a public verification
page, and authorized teachers can revoke a certificate that was issued in
error.

A unified formation-history view, mentorship, goals, and private class journals
remain future work.

Read the [Discipleship product guide](/product/discipleship) to set up
permissions, build a pathway, configure quizzes, assign teachers, publish a
version, and understand the member experience.


# Discipleship connects mentors and members
Source: https://docs.thefaithapp.com/changelog/2026-07-28-discipleship-connects-mentors-and-members

Churches can shape staff-led mentorship programs, pair members with mentors, and keep shared check-ins in one protected journey.

# Discipleship connects mentors and members

Discipleship now supports a complete staff-led mentorship journey alongside
classes and pathways. Churches can shape the program, pair an existing member
with a permissioned staff mentor, and keep their conversations and next steps
connected over time.

## Mentorship that fits the church

Admins and teachers can create mentorship programs with a church-specific
name, description, duration, meeting rhythm, and check-in prompt. They can
also decide whether members may add their own shared check-ins.

Discipleship managers assign members to staff who already have an appropriate
Discipleship permission. Assigned teachers see their own pairings, while
managers retain a church-wide view.

## One shared journey

Mentors can add conversation summaries and next steps, manage the pairing's
active or paused state, and mark the journey complete. Check-in content is
encrypted when stored.

Members can open **Mentorship** from the mobile Discipleship screen to see
their mentor, program rhythm, and shared timeline. When member contributions
are enabled, the member can add a check-in after seeing clearly that it will
be visible to the mentor.

Shared check-ins do not replace a private journal. Personal goals and private
class journals remain separate future work.

Read the [Discipleship product guide](/product/discipleship) to create a
program and pair mentors with members.


# Discipleship remembers every formation step
Source: https://docs.thefaithapp.com/changelog/2026-07-28-discipleship-remembers-every-formation-step

Members and church teams can review pathway history, preserve certificates, and begin new formation cycles without losing earlier progress.

# Discipleship remembers every formation step

Discipleship now keeps a lasting formation history when a member completes or
repeats a pathway. Earlier progress, curriculum versions, completion dates,
and certificates remain available instead of being replaced by the newest
enrollment.

## One timeline across pathways

Church teams can open **Formation History** to review enrollment cycles across
membership, baptism, new-believer, serving, leadership, and custom pathways.
They can search and filter the timeline, inspect the exact pathway version used
for each cycle, and open its certificate record.

Members have their own Formation History in the mobile app, with a concise
summary and a cycle-by-cycle view of progress and certificates.

## Repeat pathways with church-defined rules

Admins and assigned teachers can decide whether members may repeat a pathway
and set a waiting period after completion. Open pathways can begin immediately
when eligible, approval-based pathways return to staff review, and invite-only
pathways remain teacher-controlled.

Authorized staff can also start a fresh cycle from Formation History when a
member needs help. The new cycle uses the current published curriculum while
the member's earlier record remains unchanged.

The pathway library also includes a new church-editable **Serving
foundations** starting point.

Read the [Discipleship product guide](/product/discipleship) to configure repeat
rules and review formation history.


# Gifts find open serving needs
Source: https://docs.thefaithapp.com/changelog/2026-07-28-gifts-find-open-serving-needs

Churches can shape discernment instruments that keep member results private, invite trusted mentor affirmation, and connect strong gifts to real opportunities.

# Gifts find open serving needs

Discipleship now helps a church move from reflection to a real serving next
step without treating a score as a permanent label or exposing private member
answers to instrument authors.

## Shaped by each church

Admins and teachers can customize the introduction, response scale, gift or
temperament areas, questions, weights, serving-skill links, and dormant-gift
timing. Publishing creates a fixed version, so later edits do not rewrite an
earlier member result.

Volunteer opportunity editors can now assign the serving skills each open need
uses. Member recommendations include only active, available opportunities and
name the gift that explains each match.

## Private first, shared by choice

Answers and results are encrypted and private to the member. A member may
choose an active assigned staff mentor to see one result. Only that mentor can
open it and add a shared affirmation, and the member can revoke access later.

## From pattern to practice

Members can join an opportunity or request approval directly from the result.
If a strong gift has not found a serving rhythm after the church's chosen
period, the app gently resurfaces it for another look or a mentor conversation.

Read the [Discipleship product guide](/product/discipleship) to connect gift
areas, serving skills, and open opportunities.


# Personal formation stays personal
Source: https://docs.thefaithapp.com/changelog/2026-07-28-personal-formation-stays-private

Members can follow private discipleship goals and keep encrypted class reflections while churches provide customizable starting points without reading private progress.

# Personal formation stays personal

Members now have a private place for personal discipleship goals and class
reflections. Churches can offer thoughtful starting points without turning
personal formation into a staff-monitoring dashboard.

## Church-shaped starting points

Admins and teachers can create goal templates for prayer, Scripture,
community, service, rest, generosity, or another formation area. Each template
can include a suggested duration and a private progress prompt.

Members decide whether to use a template. They can rename and personalize it
or create a goal of their own. Goal wording, progress, and reflections are not
shown to staff.

## Private progress and reflection

In the mobile app, members can record private goal check-ins, pause or resume
a goal, and mark it complete. They can also keep an encrypted general journal
entry or link a reflection to one of their own class cycles.

Only the member can read, edit, or permanently delete these entries. Private
goal and journal content is separate from the shared check-ins used in a
mentor/mentee pairing.

Cohort-linked journals remain unavailable until a dedicated Discipleship
cohort workflow exists.

Read the [Discipleship product guide](/product/discipleship) to create goal
starting points and understand the privacy boundary.


# Seasonal Rules of Life stay private
Source: https://docs.thefaithapp.com/changelog/2026-07-28-seasonal-rules-of-life-stay-private

Churches can shape prayerful seasonal rhythms while every member writes and revisits a private covenant without streaks or scores.

# Seasonal Rules of Life stay private

Discipleship now helps churches invite members into a prayerful rhythm for a
season without turning formation into another performance tracker.

## A shape the church can make its own

Admins and teachers can create a season with its own name and dates, opening
invitation, covenant prompt, closing reflection, and practice guidance.
Prayer, rest, work, and generosity remain represented, while churches can
rename practices, make them optional, and add practices for their own context.

## A covenant the member owns

Members begin with the church's invitation, then write their own covenant and
commitment for each practice. They can save a draft, covenant it when ready,
revise it during the season, and close it with a private reflection.

Those words are encrypted and visible only to the member. Staff see the
reusable template, not who started it or what anyone wrote.

## Grace instead of streaks

Rule of Life follows church seasons, not daily completion counts. A new season
starts as a fresh invitation, with no score or streak carried forward.

Read the [Discipleship product guide](/product/discipleship) to create a
seasonal Rule of Life.


# Sermons and Scripture stay connected
Source: https://docs.thefaithapp.com/changelog/2026-08-11-sermons-and-scripture-stay-connected

Members can move from a live service to sermon study, offline listening, Bible plans, Scripture sharing, and gentle private review.

# Sermons and Scripture stay connected

The sermon library now supports dedicated series, offline audio, editable
private notes, published clips, and church-selected next actions for giving,
groups, and events.

Live services can notify members when a broadcast begins. Churches managing
their own stream can also add a WebVTT caption track and connect the service to
an existing on-demand sermon after the broadcast.

## Bible plans shaped by the church

Church leaders can publish individual, church-wide, and family reading plans
with ordered Scripture, reflections, household prompts, grace days, and
optional repair. Members can enroll directly from a Home recommendation when a
plan is available.

## Private, gentle Scripture practice

Members can share the Verse of the Day as an image and add verses to a private
spaced-review list. Notes, progress, recall ratings, and offline files remain
owned by the member rather than becoming a leaderboard or staff score.

Read the [Sermons and Bible Formation guide](/product/sermons-and-bible-formation)
for setup steps and current platform boundaries.


# Volunteers serve with clarity and care
Source: https://docs.thefaithapp.com/changelog/2026-08-25-volunteers-serve-with-clarity-and-care

Churches can build healthy teams, publish safer schedules, close coverage gaps, prepare worship services, and give members one Volunteer Hub.

# Volunteers serve with clarity and care

The new **Schedule & Teams** workspace brings ministry roles, team rosters,
availability, service plans, coverage, swaps, attendance, training, wellbeing,
recognition, and worship preparation together.

## A schedule that respects the person

Leaders see explicit warnings for blockouts, overlapping commitments, serving
load, rest windows, and required clearances before publishing. Members still
choose whether to confirm, decline, request a swap, or claim an eligible open
role. Standby alerts help close a real gap without bypassing those safeguards.

The restricted wellbeing view uses serving patterns and private post-service
check-ins as prompts for a caring conversation, not as labels or automatic
decisions. Members control their serving Sabbath, preferred load, reminder
channels, and private recognition.

## One place to prepare

The mobile **Volunteer Hub** includes each assignment, role instructions,
run-of-show, training, availability, blockouts, check-in, calendar feed,
thank-yous, and milestones. Assignment and training reminders respect quiet
hours, communication choices, and email or SMS consent.

The staff workspace uses a calmer responsive layout for quick scanning, while
member actions open in keyboard-safe bottom sheets that work in portrait and
landscape.

## Worship plans travel with the team

Worship leaders can build setlists and complete run sheets with timing, cues,
stage positions, production notes, arrangements, chord charts, rehearsal
tracks, song files, stems, and CCLI details. Musicians can transpose a stored
chart and start an audible BPM metronome from their assignment.

Read the [Volunteers and Serving Teams guide](/product/volunteers-and-serving-teams)
for setup and day-to-day workflows.


# Giving distinguishes received gifts from payment attempts
Source: https://docs.thefaithapp.com/changelog/2026-08-26-giving-distinguishes-received-gifts-from-payment-attempts

Giving is now a root product with trustworthy totals, one gift ledger, granular access, and immutable financial history.

# Giving distinguishes received gifts from payment attempts

Church finance teams can now open **Giving** as its own root product instead of
looking for Donations inside Church Management. The existing overview, gifts,
recurring gifts, funds, public links, and payment-provider workflows remain in
place.

## Received money stays trustworthy

Giving now distinguishes received gifts from pending, failed, and cancelled
payment attempts. Only received gifts increase overview totals, averages,
trends, payment-method summaries, donor summaries, dashboard giving totals,
and ordinary exports.

The Gifts list still keeps other attempts available for support and follow-up.
Each row and detail view displays its status, and staff can filter the list to
find a particular state.

## Financial history is protected

A received gift can no longer be edited or deleted in place. This prevents a
settled financial record from quietly changing after it has already appeared
in reporting. Authorized staff can instead record a reasoned correction or
reversal, and refunds or disputes appear as immutable audit entries.

General gifts and Outreach Campaign cash support now appear in one searchable
staff ledger with their source still visible. Each record separates the gift,
gross payment, fees, refunds, disputes, and net settlement, while granular
permissions control donor details, exports, adjustments, reconciliation, and
provider settings.

Read the [Giving guide](/product/giving-and-finance) for the current staff
workflow.

## Receipts, recovery, and finance controls

Members can review gift acknowledgements and their recurring gifts in one
place. They can pause or resume a recurring gift and change its future amount,
frequency, or fund without changing the original gift. Failed schedules now
show clear retry and action-required states instead of silently disappearing.

Stripe checkout now records when a member closes the payment sheet, preserves
the gift's fee breakdown when a declined card is retried, and accepts a later
successful confirmation for the same checkout. Refunds and disputes now keep
acknowledgements aligned with the remaining received amount, while an
acknowledgement with no remaining received amount is voided and cannot be
resent as current.

Flutterwave v3 checkout now records the donor's gross charge, provider fee,
settled amount, and provider reference from the verified transaction. Signed
webhooks and callback-first confirmations can safely arrive more than once,
and a declined or closed checkout stays available for support without
increasing received-gift totals. Recurring Flutterwave choices remain hidden
until the church account is approved and enabled for automated tokenized card
charges.

PayPal hosted checkout now records when a member closes the approval screen
and keeps PayPal's processor fee separate from the platform fee in the gift
breakdown. Connected churches with PayPal's partner Subscriptions capability
can now receive recurring general and campaign gifts. PayPal owns the schedule
and retries, while Giving reconciles every charge and synchronizes pause,
resume, cancellation, failure, and lifecycle status.

Finance teams can prepare controlled manual-gift batches, match provider or
bank deposits to received gifts, and export allocation and settlement details
in a provider-neutral format. Corrections, fund closure, batch close, and
reconciliation close now wait for a different authorized person before they
take effect.

## Statements and accounting handoff

Finance teams can issue period and year-end statements from received gifts,
with separate totals for each currency. Churches control their jurisdiction,
registration details, address, and legal wording, and year-end issuance stays
off until those settings are deliberately enabled. Household statements require
explicit authorization and an adult household contact.

Members can privately download their issued statements or request another
email. If a statement needs correction, a different authorized person reviews
the new version while the earlier version remains in the financial history.

Funds and reconciled deposits can now carry accounting codes and account names
into the provider-neutral finance export, giving future accounting connections
a stable mapping contract.

## Safer ways to reach the giving page

Churches can prepare a general or active-fund link and download a QR image or
standard NFC URI record for it. Both open the public giving page without
starting a payment.

Church-owned text-to-give keywords can reply through the signed Twilio inbox
with a short-lived secure link. The text never creates or charges a gift, and
it does not enroll the sender in marketing updates.

## Campaign stewardship and impact

Churches can now add a capital, missions, or general classification to an
existing Outreach Campaign, set a monetary goal, record its funding state and
project phase, and decide deliberately whether received and pledged totals are
public. Received progress counts settled gifts only.

Members can record a monetary pledge without charging a payment method or
scheduling an automatic payment. They can review settled-gift progress, choose
or turn off email reminders, cancel a pledge, and—when authorized—include
eligible household gifts. Giving toward a pledge remains a separate checkout.

Church teams can publish reviewed campaign or fund updates and prepare an
annual generosity report from settled gifts and reviewed content. Public
reports do not include donor identities, and consent-confirmed stories remain
private until review and publication.

Members can also request a confidential conversation about stock, asset, or
legacy giving. The inquiry flow does not collect asset values, account
numbers, credentials, private keys, wills, or custody instructions.


# Admin data and governance become accountable
Source: https://docs.thefaithapp.com/changelog/2026-08-27-admin-data-and-governance-is-accountable

Churches can build reports, publish trusted resources, coordinate decisions, and protect sealed governance work in one permission-controlled product.

# Admin data and governance become accountable

The new **Admin, Data & Governance** product connects everyday church data
work with the stronger controls needed for formal governance.

## Work with data safely

Staff can build multi-filter reports, save views, schedule re-authorized
exports, define church-specific fields, preview bounded bulk changes, and test
workflow effects without sending or mutating source records. The reviewed
Forms catalog now covers every intake in this capability.

## Publish dependable church knowledge

One versioned library holds handbooks, volunteer and discussion guides,
policies, maps, training, worship files, and youth permission documents.
Members receive published resources and acknowledgements in **Church
Resources**, while source-linked search stays inside approved material.

## Keep decisions explainable

Boards and leadership teams can assemble packets, record motions and recusals,
calculate quorum, approve human-reviewed minutes, maintain annual plans, and
follow owned actions. Versioned policies, renewable covenants, membership
standing, retention rules, legal holds, and permission reviews preserve the
reason behind a decision.

## Seal the records that need it

Confidential documents use separate access. Discipline cases require named
assignment as well as permission. A public whistleblower channel routes sealed
reports only to fixed eligible recipients, excludes the accused, and never
places report content in a notification.

Read the [Admin, Data and Governance guide](/product/admin-data-governance) to
prepare roles and begin a review.


# Church networks work together with clear boundaries
Source: https://docs.thefaithapp.com/changelog/2026-08-27-church-networks-work-together-with-clear-boundaries

Trusted churches can support plants, coordinate shared ministry, and reuse resources without merging their member data.

# Church networks work together with clear boundaries

The new **Church Network** workspace connects invited churches around church
plants, campaigns, care coordination, safeguarding status, pulpit supply,
filings, and shared resources while preserving each church's local ownership.

## Practical support for church plants

Parent and plant churches can work through an editable launch checklist,
bounded support reports, planter-controlled wellbeing signals, and a shared
support taper ledger. Planned, actual, and variance totals make the agreement
visible without introducing a new payment flow.

## Shared ministry without shared databases

Networks can publish events and prayer campaigns, coordinate dated pulpit
requests with vetted profiles and monthly limits, and collect reviewed filing
submissions with source-aware roll-ups.

Care transfers require member consent, share only a bounded context, and can
be withdrawn before acceptance. A separately consented and permissioned
discipline/restoration envelope can share only the current status from an
assigned protected case; its narrative and sealed details remain at the source
church. Name-blind benevolence checks return a safe coordination reference
instead of revealing identity or case notes. Expiring safe-to-serve passports
share current claims but never the raw background report. Passport claims are
also checked against the issuing church's current local clearance record.

Network governance remains with owner, parent, and regional coordinators.
Only churches designated as plants can receive plant checklists and support
records, while member churches retain control of their own submissions.

## Resources that keep their history

Churches can publish ministry resources and templates with authorship,
versions, licenses, usage guidance, and review marks. Forked curricula and
other teaching assets keep their source lineage, while members can read
published resources and send field feedback from the mobile Church Network
hub.

Read the [Church Networks guide](/product/church-networks) for setup, daily
workflows, permissions, and privacy boundaries.


# Operations and facilities stay ready
Source: https://docs.thefaithapp.com/changelog/2026-08-27-operations-and-facilities-stay-ready

Churches can coordinate rooms, Sunday operations, equipment, safety, access, transport, weather decisions, and emergency readiness from one audited workspace.

# Operations and facilities stay ready

The new **Operations & Facilities** product brings facility calendars,
equipment, service execution, safety, access, and transport into one practical
workspace.

## Prepare the building and the service

Teams can approve room and equipment reservations, record setup and comfort
intent, manage maintenance and cleaning work, track supplies, and prepare a
Sunday run sheet with stations, parking, production, communion, and baptism
details. Publishing warns when a required resource or projection permission
still needs attention.

## Keep instructions and responsibility clear

Public-safe QR runbooks put reviewed stop-and-escalate instructions at the
equipment that needs them. Critical systems also show when only one trained
operator is recorded. Keys, safety items, drivers, vehicles, manifests, and
contractor visits stay in permission-controlled workflows.

## Coordinate emergencies without widening access

Safety teams can publish contact trees and evacuation plans, issue service
alerts, record incidents, walk through a weather closure decision, and run an
accounted-for volunteer role call. Members see only the alerts, assignments,
checklists, and safe instructions intended for them.

Read the [Operations and Facilities guide](/product/operations-and-facilities)
to set up resources and rehearse the workflow.


# Outreach connects mission work and local presence
Source: https://docs.thefaithapp.com/changelog/2026-08-27-outreach-connects-mission-and-local-presence

Churches can coordinate mission teams, publish trusted local services, verify community impact, and share reviewed stories.

# Outreach connects mission work and local presence

The new **Mission Control** workspace connects existing Outreach Campaigns and
Events with mission applications, team preparation, community partners,
prayer, service time, and impact review.

## From invitation to a prepared team

Leaders can offer direct signup, review adult mission applications, or link an
existing Event registration. Approved members receive team updates, packing
and training steps, prayer focus, and their own readiness in the mobile
**Outreach Hub**. Training may include resources and staff verification.
Adult mission applicants can also manage a separate encrypted travel-readiness
record. Restricted staff access is audited, members can delete it, and its
contents are automatically purged after the trip's retention window. Youth
travel keeps using existing Event, guardian, and waiver safeguards.

## A directory neighbors can trust

Churches can publish organization-level service profiles with opening hours,
accessibility, eligibility, referrals, contact details, and optional public map
coordinates. Old verification dates remain visible so visitors know when to
confirm information directly.

Staff can preview partner CSV rows before importing them as drafts, preview
organization coordinates without saving them, and order deliberately
published partner pins for visits without using member or beneficiary
locations.

## Impact with evidence and dignity

Only verified service time and settled campaign support enter calculated
impact. Staff can add aggregate measures without beneficiary rosters. Member
and public stories require publication consent, content safeguards, and human
approval before they appear publicly.

Fundraising continues through the existing campaign checkout and configured
payment webhooks; no additional payment integration is required.

Read the [Outreach, Missions and Local Presence guide](/product/outreach-missions-local-presence)
for setup, privacy boundaries, and day-to-day workflows.


# AI Assistance keeps people in the loop
Source: https://docs.thefaithapp.com/changelog/2026-08-28-ai-assistance-keeps-people-in-the-loop

Members can ask source-grounded church questions while staff gain permission-aware drafts, search, and transcript cleanup suggestions.

# AI Assistance keeps people in the loop

Members can now open **Ask your church** from Connect to ask about published
church information, Events, Groups, sermons, bulletins, and devotionals.
Answers show the church sources used and say when the answer cannot be verified.

## A broader staff copilot

AI Chat can now help authorized staff prepare visitor and Volunteer messages,
summarize permitted care context, explain next steps and Group options, find
duplicate candidates or schedule gaps, and draft Events, announcements, weekly
summaries, and ministry reports.

Permissions still come from the source workspace. Drafts are never sent,
published, merged, or assigned automatically.

## Safer sermon review

Staff reviewing a sermon transcript can request conservative cleanup
suggestions, apply only the suggestions they choose, and save after human
review. Sermon repurposing now includes explicit small-group guides, newsletter
summaries, and short devotionals alongside the existing reviewed outputs.

## Safeguarded sponsor-letter help

Members with an active or recovering sponsorship can translate, lightly
polish, or do both for their own letter draft. The assistant receives no
private beneficiary identity or safeguarding record, and it returns an unsaved
draft. The member must review it and submit it separately through the ordinary
moderation workflow.

Read the [AI Assistance guide](/product/ai-assistance) for workflows,
availability, source boundaries, and pastoral safeguards.


# Platform access and integrations stay portable
Source: https://docs.thefaithapp.com/changelog/2026-08-28-platform-access-and-integrations-stay-portable

Members gain private access preferences while churches gain signed webhooks, full data export, and simple month-to-month plan controls.

# Platform access and integrations stay portable

The new **Platform, Access & Integrations** workspace gives churches one honest
view of access support, developer access, data portability, and plan controls.

## Members control access preferences

The mobile **Access & data** profile applies text size, high contrast,
reading-friendly presentation, reduced motion, audio-first use, language,
caption, Data Saver, and image choices across the app. Members can privately
record interpreter, mobility, large-print, sensory, dietary, and other support
needs, then deliberately choose whether an authorized church team may see
them.

## Integrations stay with their workflows

Existing provider setup remains in Giving, Communications, Streaming, Events,
or member-data migration instead of being duplicated in a central catalog.
Church-built systems can still receive signed Event, registration, and Giving
webhooks with encrypted secrets, safe test events, delivery history, and
bounded retries.

## Churches can leave with their data

An authorized administrator can create an expiring full-church export that
redacts credentials and platform secrets. Base plans are month to month, carry
no termination fee, and can be canceled in one action without deleting church
records or donation history.

Read the [Platform, Access and Integrations guide](/product/platform-access-integrations)
to configure access support, webhooks, exports, and plan controls.


# QuickBooks and Xero connect to balanced giving journals
Source: https://docs.thefaithapp.com/changelog/2026-08-29-giving-exports-balanced-accounting-journals

Finance teams can connect a church-owned QuickBooks company or Xero organization, select live accounts, and safely send previewed journals while CSV exports remain available.

# QuickBooks and Xero connect to balanced giving journals

Church finance teams can now prepare QuickBooks- and Xero-ready journal files
inside **Giving > Finance Operations**. Each church controls its own
contribution, processing-fee, refund, settlement, and fund mappings.
Reconciled deposits can route their settlement line to the deposit's own
account instead of the profile default.

## Preview before download

Every export starts with a preview. Finance staff can check the settled-gift
record count, journal row count, balanced debit and credit totals, warnings,
and sample rows before creating a file. Missing mappings and inconsistent fund
allocations stop the export with a clear correction message.

Completed files stay in the church's export history for repeat download.
Failed validation attempts remain visible without creating a file.

## A safer accounting handoff

Accounting exports include settled gifts only and omit donor names and email
addresses. Generated files are encrypted at rest and remain inside the
church's Giving export permission boundary.

QuickBooks files use journal-entry account names and import columns. Xero files
use account codes and manual-journal columns. Finance teams should still review
the provider's import preview before posting the journal.

## Connect and send to QuickBooks or Xero

Authorized finance users can now connect a church-owned QuickBooks company or
Xero organization from the same Giving workspace. A connected profile uses the
live chart of accounts, and a completed preview can send one balanced journal
per settled gift. Delivery history shows whether a run was sent or needs a
corrected mapping and another attempt.

Xero's Demo Company supports safe setup and test delivery. The connected card
shows the organization's base currency, and account selection prevents a
manual journal from using a bank account. Finance teams can use a non-bank
clearing account for settlement lines instead.

Retries reuse the same request identity and do not post a completed run twice.
Access tokens remain encrypted and rotate automatically. Disconnecting revokes
provider authorization without deleting earlier exports or accounting
records.

When an approved refund, dispute, or correction changes a gift after delivery,
TheFaithApp sends a dated reversal of the earlier journal and a corrected
replacement. If that two-part correction is interrupted, retrying resumes it
without duplicating the reversal.

CSV exports for either provider still require no connected account.

Read the [Giving guide](/product/giving-and-finance) for setup and export steps.


# Member migrations preview every outcome before import
Source: https://docs.thefaithapp.com/changelog/2026-08-29-member-migrations-preview-before-commit

Move people from Planning Center, Breeze, Subsplash, Tithe.ly, or another CSV with provider-aware mapping, duplicate review, and a safe undo path.

# Member migrations preview every outcome before import

Church teams can now choose the system a member CSV came from and review what
will happen before adding anyone to the directory.

* Start from Planning Center People, Breeze ChMS, Subsplash People, Tithe.ly
  People, or a general CSV template.
* Review suggested mappings for names, contact details, provider IDs,
  demographics, addresses, and joined dates.
* See accepted, duplicate, rejected, and empty-row counts before committing.
* Download duplicate and rejected rows with clear reasons for correction.
* Import only accepted rows, then undo that migration from Import History if
  the source file needs to be corrected.

Uploaded files and review reports are encrypted while stored. Migration access
is limited to the church and its authorized Members staff, and audit history
keeps outcome counts without copying member contact details or raw CSV values.

Imported members are not invited automatically, giving staff time to review
the directory before sending access invitations.


# Private calendars stay useful and private
Source: https://docs.thefaithapp.com/changelog/2026-08-29-private-calendars-stay-private

Churches can share automatically updated Event and service schedules without exposing member details or internal planning notes.

# Private calendars stay useful and private

Authorized administrators can now create named, read-only calendar
subscriptions in **Events** for published public Events, one campus's services,
one ministry's schedule, or all volunteer services.

Each subscription works with Apple Calendar, Google Calendar, Outlook, and
other calendars that support iCal subscriptions. Because it is a subscription
rather than a one-time file export, future schedule changes appear when the
calendar provider refreshes the feed.

## Access that can be changed safely

The private URL is shown only after creation or an explicit **Reveal and copy**
action. Administrators can give every trusted person, display, or external
calendar its own named URL, then rename, rotate, or revoke it independently.

Rotating a URL immediately disables the previous one. Revoking stops the
calendar from updating until an administrator creates a new URL.

## Only the schedule leaves the platform

Shared calendars include published schedule titles, times, locations, and the
relevant campus or ministry name. Drafts, registrations, assignments, member
names, safeguarding information, and internal notes stay out of the feed.

Existing member serving subscriptions receive the same stronger token storage
and continue to show only that member's published commitments.

Read the [Events and Volunteers guide](/product/events-and-volunteers) for
setup steps for Apple Calendar, Google Calendar, and Outlook.


# YouTube Live becomes an on-demand sermon
Source: https://docs.thefaithapp.com/changelog/2026-08-29-youtube-live-becomes-an-on-demand-sermon

Finished YouTube Live services can now appear automatically in the sermon archive after YouTube finishes processing the recording.

# YouTube Live becomes an on-demand sermon

Churches that stream with YouTube Live can now turn a finished service into an
on-demand sermon without copying a recording URL back into TheFaithApp.

In **Streaming**, save the YouTube Live video ID, choose the sermon category
under **Automatic on-demand archive**, and click **Enable YouTube archive**.
TheFaithApp checks the broadcast after it ends and creates the sermon only when
YouTube says the recording is processed and playable.

## The recording keeps its useful details

The new sermon uses the YouTube title, description, duration, and best available
thumbnail. The livestream is marked inactive and linked to that sermon. Repeat
checks do not create duplicate sermons.

## No new church credentials

The connection reuses TheFaithApp's existing YouTube API integration. Churches
do not enter a YouTube password or copy a webhook secret. Other streaming
providers can continue using the signed recording-ready webhook.

If YouTube is still processing the recording, TheFaithApp waits and checks
again. A rejected recording is shown as a failed archive event instead of
creating a broken sermon.

Read [Content Management](/product/content-management#streaming) for setup
steps and the available live sources.


# Pricing makes product capacity clear
Source: https://docs.thefaithapp.com/changelog/2026-08-30-pricing-makes-product-capacity-clear

Church management remains free for small churches while every plan now shows its products, allowances, add-ons, and data guarantees.

# Pricing makes product capacity clear

Churches can now see what each TheFaithApp plan includes before a limit affects
their work. Core church management remains free for churches with up to 100
members, while the wider product suite uses practical starter allowances.

## A clearer product comparison

The public pricing page now compares member capacity, staff administrators,
branches, Giving, Forms, communication, Outreach, Children & Youth,
Discipleship, Analytics, Operations, Governance, integrations, customization,
and support in one table.

Standard unlocks the complete single-church suite. Large adds multi-branch
operations, advanced governance, API access, webhooks, and custom domains.
Enterprise adds Church Networks, custom integrations, and guided support.

## Allowances are visible before they interrupt work

The Billing overview now shows each church's live plan usage, including member
profiles, staff administrators, branches, open Giving funds, published Forms,
monthly responses and campaigns, Outreach, Discipleship, and Children & Youth
check-ins. Staff receive a clear upgrade response when a new record would pass
an allowance; existing records remain available.

## Add-ons are separate and visible

Digital Ministry Assistant is shown at $29 per month, matching dashboard
billing, and Prayer Rooms Plus is shown at $19 per month. Churches can add
either without changing their base plan.

## Records remain the church's records

Full export stays available on every plan. Downgrades preserve existing
records, and giving receipts, safeguarding history, and incident history remain
accessible rather than being deleted because a plan changed.


# Churches control member AI access
Source: https://docs.thefaithapp.com/changelog/2026-08-31-churches-control-member-ai-access

Ask your church is now an explicit church-paid choice with administrator control and a per-member fair-use safeguard.

# Churches control member AI access

**Ask your church** now appears in the member app only after a church activates
the paid Digital Ministry Assistant add-on and a billing administrator enables
member access.

Member questions draw from the church's shared monthly reply allowance. Each
member can ask up to five questions per day so one person cannot consume the
whole church allowance. The five free AI replies remain available for staff
evaluation and cannot be used from the member app.

Billing administrators can turn member access on or off at any time from
**Settings > Billing & Subscription > Add-ons**. Turning it off removes the
entry from Connect without affecting the church's published sermons, Events,
Groups, bulletins, or devotionals. Each access change is recorded in the
church's audit history.

Read the [AI Assistance guide](/product/ai-assistance) for source boundaries,
usage rules, and pastoral safeguards.


# Paid plans now have clear growth limits
Source: https://docs.thefaithapp.com/changelog/2026-08-31-paid-plans-have-clear-growth-limits

Standard, Large, and Enterprise now scale through published allowances instead of repeating unlimited access.

# Paid plans now have clear growth limits

Churches can now see a meaningful capacity increase at every paid plan. Standard
supports a growing single church, Large supports multi-branch operations, and
Enterprise supports networks and higher-volume ministry.

## Clear capacity at every step

Standard, Large, and Enterprise now publish increasing limits for staff
administrators, branches, Giving funds, Forms, monthly responses and campaigns,
Outreach, Discipleship, Children & Youth check-ins, scheduled reports, and
webhook endpoints.

The updated monthly prices are $39 for Standard, $79 for Large, and $149 for
Enterprise. Enterprise includes 2,000 members, with additional 500-member blocks
available for $10 per month.

## Limits appear before they interrupt work

Billing shows live usage and remaining capacity for the church's current plan.
When a new action would exceed an allowance, the app identifies the limit and
the next plan with enough capacity. Existing records remain visible and full
data export stays available.

Paid-only product actions follow the same rule. New governance work requires
Standard, developer API and integration setup requires Large, and Church
Network changes require Enterprise. A church that downgrades can still view,
export, deactivate, or remove its existing records instead of losing access to
its data.

## Reliable integrations remain reliable

Integrations are limited by active webhook endpoints rather than silently
dropping deliveries after a hidden event quota. Large includes 5 active
endpoints and Enterprise includes 25.


# Client onboarding is now invitation-only
Source: https://docs.thefaithapp.com/changelog/2026-09-03-client-onboarding-is-now-invitation-only

Churches can request access while Super Admins review fit and send secure, private account setup links.

# Client onboarding is now invitation-only

New church accounts now begin with a reviewed access request instead of an
open registration form. Prospective churches can explain their goals, timing,
team size, and current tools before TheFaithApp creates an account.

## A clearer path for prospective churches

The public **Request access** page explains what happens next and keeps the live
demo and demo-call options nearby. Submitting the form confirms receipt without
automatically creating an account. It alerts the platform review inbox at that
point rather than sending new-registration messages after account setup.

## One review workspace for Super Admins

The new **Client Onboarding** workspace collects public requests and direct
invitations. Super Admins can search the queue, record discovery notes, mark a
church as contacted or qualified, and send, resend, revoke, or decline an
invitation.

Invitation activity shows when a link was sent, opened, and due to expire.

## Private account setup

Approved contacts receive a single-use invitation tied to their email address.
Links expire after seven days, rotate when resent, and stop working after they
are revoked or accepted. The church account and its first administrator are
created together only after the invited setup is completed. Accepting the
email-bound invitation verifies the address without a second verification or
welcome-email sequence.

The sign-in page no longer advertises public account creation. New
administrators reach setup only through their private invitation.


# Add members to a group straight from the Members list
Source: https://docs.thefaithapp.com/changelog/2026-09-16-add-members-to-a-group-in-bulk

Tick any number of members, choose a community group, and add them all at once; anyone already in the group or beyond its capacity is reported rather than duplicated.

The bulk bar on the Members list now has **Add to group** beside Add tag,
Message, and Export. Tick the members you want, pick a community group from
the list, and click **Add to group**.

Everyone selected joins the group as an active member, approved by you, the
same way as adding them one at a time from a member's connections. Members who
are already in the group are left as they are. If the group has a capacity and
fills up part-way through, the remaining members are not added and the
confirmation says how many were left out.


# Assign a follow-up to any member
Source: https://docs.thefaithapp.com/changelog/2026-09-16-assign-follow-ups-to-members

From a member profile, assign a call, text, email, or visit to a colleague with a due date, mark it done with an outcome, and see it in the dashboard follow-up list and the attention bell.

Follow-ups used to exist only for visitors. Every member profile now has an
**Assign follow-up** button in the header. Say what needs to happen, how
(phone call, text message, email, in person), who owns it, and when it is
due. Leave the owner as "Me" to keep it yourself.

Open follow-ups appear in a new **Follow-ups** section in the profile sidebar
with an "Open follow-ups" count in the header. **Mark done** records what
happened; the follow-up then moves into the activity timeline as
"Follow-up completed".

The dashboard's "Follow-ups due today" tile and list, and the "overdue
follow-ups" line in the attention bell, now count member follow-ups alongside
visitor follow-ups. A member follow-up in the dashboard list opens the
member's profile.


# Public devotionals page: topic filters, email sign-up, and the app
Source: https://docs.thefaithapp.com/changelog/2026-09-16-devotionals-page-topics-and-email-signup

Visitors can filter devotionals by topic, subscribe by email to get new devotionals from the church, and jump to the mobile app from the same page.

The public Devotionals page now does more than list posts.

**Topics.** The tags you put on devotionals appear as chips under the search
box, most used first, with a count. A visitor taps one to see only those
devotionals, and each card shows its own topics.

**Subscribe by email.** A sign-up card below the search asks for an email
address. Each address lands in **Marketing → Email Subscribers** with the
source "Devotionals", so you can send new devotionals to everyone who asked.
Someone who unsubscribed and signs up again is re-subscribed; someone already
on the list is told so.

**Get the app.** When the church's mobile app link is configured, the same
card offers "Get the app", opening the store link that the dashboard QR code
uses.


# Event pages: add to calendar, share, and registration options
Source: https://docs.thefaithapp.com/changelog/2026-09-16-event-page-calendar-share-and-options

Public event pages gain Google Calendar and Apple/Outlook calendar links, a share button with copy-link feedback, and optional registration checkboxes such as "Bring a dish" that you define per event.

The public event page's registration card now has three actions at the top:
**Google Calendar**, **Apple / Outlook** (a calendar file for the chosen
date), and **Share**, which opens the phone's share sheet or copies the link
and says so.

Events can also carry **registration options**: short checkboxes a guest
ticks while registering, such as "Bring a dish" or "Need childcare". Add them
under the event's registration settings, one per line. Guests see them on the
public page, their choices show on the confirmation, in the occurrence
workspace, and in the registrations CSV.

Spots remaining were already shown on the page and are unchanged.


# Member profiles bring everything about a person together
Source: https://docs.thefaithapp.com/changelog/2026-09-16-member-profiles

Open any member to see their activity, giving, groups, household, and care in one place, and keep notes and tags on the record.

Every member now has a full profile page. Click a name in the Members list to
open it, or share its link with another admin.

The profile shows one activity timeline that joins visits, follow-ups, gifts,
attendance, care cases, form responses, and group changes, with filters for
each. Beside it sit the member's contact details, household, groups and serving
roles, giving summary, and any open care cases.

Staff can now add notes to a member and mark them as visible to all staff or to
pastoral staff only, and add tags such as "Hospitality team" or "Baptism
interest" that will power directory filters in a coming update.


# The Members list is now a working directory
Source: https://docs.thefaithapp.com/changelog/2026-09-16-members-directory-workspace

Saved views, filters for tags, groups, sign-in and giving, sortable columns, a column chooser, CSV export, and bulk tagging.

The Members list now works like a directory rather than a plain table.

Pick a view across the top (All, Active, Inactive, New this month, Not in a
group, Never logged in, Lapsed givers) or save your own combination of filters
as a named view. The summary tiles above the list act as shortcuts to the
matching view.

Filter by status, gender, group, tag, or giving. Sort by name, groups, or last
login. Choose which columns you want to see; your choice is remembered on this
browser. Export the current view, or a selection, as a CSV.

Tick members to open the bulk bar: add a tag to everyone selected, jump to
Communications to message them, or export just those rows. Clicking a row
opens the member's profile.


# Pastoral notes are now only visible to pastoral staff
Source: https://docs.thefaithapp.com/changelog/2026-09-16-pastoral-notes-stay-with-pastoral-staff

A member note marked "Visible to pastoral staff" is hidden from admins without the Pastoral Care permission, in the notes list, the activity timeline, and when deleting; the toggle only appears for staff who can use it.

When member profiles launched, a note could be marked "Visible to pastoral
staff", but every admin who could open the profile still saw it. That is now
enforced.

Admins whose role does not include the **Pastoral Care** permission no longer
see pastoral notes anywhere on the profile: not in the notes list, not in the
activity timeline, and they cannot delete or write one. For them the note box
simply says "Visible to all staff" with no toggle.

Church administrators and anyone in a role with Pastoral Care see and manage
both kinds of notes as before.


# The dashboard now opens with people
Source: https://docs.thefaithapp.com/changelog/2026-09-16-people-first-dashboard

New visitors, follow-ups due today, open care cases, and this month's gifts sit at the top, with today's follow-up list, what needs attention, recent activity, and a giving trend.

The dashboard now leads with the people side of church life instead of media
and setup.

Four tiles show new visitors this week, follow-ups due today (with how many are
overdue), open care cases (urgent and unassigned), and gifts this month
including first-time givers. Each tile opens the matching screen.

Below them: today's visitor follow-ups with who owns each one, a "needs
attention" list shared with the header bell, a feed of recent connect cards,
gifts, form responses, care requests, and group joins, and a twelve-week giving
trend with a week-over-week change.

Church information, the subscribe QR code, the changelog, and media and bulletin
statistics are still on the page, under "Church setup and content".


# Public forms load reliably on church websites
Source: https://docs.thefaithapp.com/changelog/2026-09-16-public-forms-load-reliably

Embedded and shared forms now open correctly when the church site and TheFaithApp run on different domains.

Forms shared by link or embedded on a church website could show "Form unavailable"
even when the form was published. This happened when the church site and
TheFaithApp were on different domains. Forms now load and submit correctly in
that setup.

If a form really is unavailable, the page now explains that it could not be
loaded, rather than suggesting a submission failed.


# Every public church page shares one header and footer
Source: https://docs.thefaithapp.com/changelog/2026-09-16-public-pages-shared-header

Visit, Connect, Devotionals, Campaigns, Outreach, Give, and Prayer Request now carry the same navigation, a Give button, and a footer with the church's details.

The public pages a church shares with visitors now look like one site. The
header on every page shows the church name and logo, links to Visit, Connect,
Devotionals, Campaigns, and Outreach, a Give button, and the sign-in control.
The giving and prayer-request pages, which used to stand apart, use the same
header.

A footer on each page shows the church's name, location, and email, plus links
to its website, the prayer-request form, and the connect card.

Pages embedded in a church website with `?embed=1` still hide the header and
footer so they sit cleanly inside the site's own layout. On phones the links
are easier to tap.


# Search everything from the header, and see what needs attention
Source: https://docs.thefaithapp.com/changelog/2026-09-16-search-and-attention-bell

A search box on every dashboard page finds members, visitors, care cases, and pages, and a bell shows overdue follow-ups, unowned or urgent care, profile changes, and new form responses.

The dashboard header now has a search box. Click it or press Cmd+K (Ctrl+K on
Windows) from any page, then start typing a name, email, or phone number. Results
are grouped into People, Visitors, Care, and Pages; use the arrow keys and Enter
to jump straight to a member profile, the visitor inbox, pastoral care, or any
screen in the sidebar.

Next to your profile menu, a bell shows a dot when something needs a person:
overdue visitor follow-ups, care cases without an owner, urgent care cases,
profile changes waiting for review, and new form responses. Each line links to
the screen where it is handled. The bell refreshes on its own every couple of
minutes.


# A People group at the top of the sidebar
Source: https://docs.thefaithapp.com/changelog/2026-09-17-people-group-in-the-sidebar

Dashboard, Members, Visitor Inbox, Pastoral Care, Donors & Giving, Households, Groups, and Communications now sit together in one sidebar group that opens by default after sign-in.

The sidebar now starts with **People**: Dashboard, Members, Visitor Inbox,
Pastoral Care, Donors & Giving, Households, Groups, and Communications. It is
the group that opens after sign-in and whenever you land on one of those
pages, so the day-to-day work of a church is one click away.

Nothing has moved. Church Management, Giving, and the other products keep
every page they had; People is a second door to the same screens. Households
and Groups open the matching tab on the Members page, and the header search
lists each page once.

The product list also gains a People tile, and the Church Management tile now
opens its own dashboard.


# A clearer start for your church
Source: https://docs.thefaithapp.com/changelog/2026-09-25-church-setup-guide

Start without a logo and follow three practical setup steps from the dashboard.

Invited churches can create an account without uploading a logo. The default
TheFaithApp mark appears until a church adds its own in **Settings → Church
Profile**, so church pages still have a usable image.

The main administrator's dashboard now includes **Get your church ready**:
church identity, the first member, and a published public form. Progress
updates from saved data when you return to the dashboard, and the guide
collapses once all three essentials are in place.

Private invitations are still required, email-bound and single-use. Read
[Client onboarding](/product/client-onboarding) for the complete process.


# Clearer public forms and navigation
Source: https://docs.thefaithapp.com/changelog/2026-09-25-focused-public-forms

A compact church menu and more comfortable forms on phones, tablets, and desktop.

Public church navigation now fits smaller screens without pushing **Give**
outside the page. Open the church menu to reach every section and the giving
page.

Connect cards, published forms, giving, and prayer requests keep the navigation
compact on desktop too. Published forms have one clear title, more comfortable
field spacing, and a quieter footer. Embedded forms retain church branding
without duplicating the surrounding website navigation.

Read [Public church pages](/product/public-church-pages) for sharing and
embedding guidance.


# From access request to an active church
Source: https://docs.thefaithapp.com/changelog/2026-09-26-acquisition-and-activation

Add members directly, recover from connection problems, and see real church setup progress.

* **Add New Member** is available on the Members page, alongside CSV import.
  Failed saves retain entered details, and successful saves refresh the directory.
* Access requests receive a receipt email, without implying approval or promising
  a review deadline.
* Invitation and dashboard loading errors offer a retry. Public forms retain
  answers through background refreshes and guard against repeated submissions.
* Super Admins can distinguish created accounts from churches with a member,
  published public form, and first completed non-spam response.
* An optional source-to-activation report uses consented campaign labels, with
  90-day retention and a control to remove attribution on consent withdrawal.

Read [Client onboarding](/product/client-onboarding) for the complete process.


# A calmer dashboard for daily work
Source: https://docs.thefaithapp.com/changelog/2026-09-26-focused-dashboard

See what needs attention first, with setup and detailed reports available when you need them.

The dashboard now brings follow-ups and attention alerts together under
**Today's priorities**. When no action is needed, one compact message replaces
the empty panels.

* Church setup shows saved progress and the next unfinished step. Expand
  **Setup steps** to review the full checklist.
* The four people and giving totals remain directly accessible.
* Expand **Recent activity and giving trends** for the activity feed and giving chart.
* Expand **Church setup and content** for church information, the subscribe QR
  code, changelog, and detailed summaries.
* Unavailable priority data shows a retry option instead of suggesting there is
  nothing to do.

Read [Dashboard and Internal Tools](/product/dashboard-and-internal-tools).


# Connect a new or existing Stripe account
Source: https://docs.thefaithapp.com/changelog/2026-10-02-connect-existing-stripe-account

One Stripe connection flow for new and existing Standard accounts, with verified payment readiness and safer disconnects.

Payment Providers now offers **Connect with Stripe** through OAuth.
On Stripe, select your existing Standard account or create a new one, then
authorize TheFaithApp. Either choice keeps your church's Stripe dashboard. There is no separate
account-creation flow in TheFaithApp.

* Resume unfinished OAuth connections and complete missing information in Stripe.
* Receive gifts only after Stripe confirms the connected account is ready.
* Disconnecting revokes TheFaithApp's access before removing the connection,
  without deleting the Stripe account.
* Accounts with platform controls show the Stripe Dashboard action
  required if they cannot be disconnected automatically.

Existing connections remain in place. Changing accounts does not transfer
Stripe subscriptions or payment history.

Read [Giving](/product/giving-and-finance#connect-stripe).


# A smoother first church journey
Source: https://docs.thefaithapp.com/changelog/2026-10-03-first-church-journey

Move from signup to a useful form and visitor follow-up with fewer interruptions.

Invited administrators now continue from account creation directly to the
dashboard. If sign-in cannot finish, the recovery page confirms the account is
ready and prefills the email, so the invitation does not need to be reused.

Church logos remain optional throughout setup. The dashboard recommends adding
a member and publishing a form, then points to response review when a public
response arrives.

Form settings and manager selections save together. A standard public form can
save without selected managers, and any correction appears in the settings
dialog.

Connection cards require an email or phone number when a visitor asks to be
contacted. Staff can see a guest's supplied name when they have permission to
view it, while sensitive answers stay protected.

Read [Client onboarding](/product/client-onboarding) and
[Forms](/product/forms) for the updated steps.


# Save members first and follow up clearly
Source: https://docs.thefaithapp.com/changelog/2026-10-03-member-invitations-and-follow-up

Choose when to invite a member, correct contact details on mobile, and explore a useful demo response.

Adding a member now saves a record by default. Email is optional until you
choose to send a welcome invitation. Invite someone immediately with the
explicit checkbox, or send their invitation later from the directory.

Response follow-up fields keep their labels visible. Public connection cards
bring missing contact details into view when a visitor asks for a reply.
Collapsed navigation, its toggle, and the account and language menus have
accessible names; navigation toggles also work with the keyboard.

The live demo includes a clearly fictional visitor response with an assigned
owner, a next-step note, and a dashboard priority. Explore it through
**Forms → Responses**.

Read [Members directory](/product/members-directory) and [Forms](/product/forms)
for the updated steps.


# Open product menus with your keyboard
Source: https://docs.thefaithapp.com/changelog/2026-10-04-keyboard-product-menus

Use the collapsed sidebar with Tab, Enter, Space, arrow keys, and Escape.

Collapsed product menus now join the Tab order and show a visible focus outline.
Press **Enter** or **Space** to open a menu, use arrow keys to move between
choices, and press **Enter** to open the selected page.

Nested menus support arrow-key entry and return. **Escape** closes the menu and
returns focus to its opener. Hover and click remain available, and unavailable
actions are skipped during keyboard navigation.

Read [Admin navigation](/product/admin-navigation) for the keyboard steps.


# Read member cards and choose a useful follow-up method
Source: https://docs.thefaithapp.com/changelog/2026-10-05-member-directory-and-follow-up

Read member names on phones, use available contact details for follow-up, and identify response dates and saved views more easily.

The Members directory uses cards on phones so names, contact details, and
actions stay readable. Select a name or **View** to open a profile; selection,
sorting, connections, and invitation actions remain available.

Member follow-up starts with **Phone call** when a phone number is recorded,
**Email** when only email is recorded, or **No channel** when neither is
available. A hint explains missing contact details for a selected method.
In-person and task-only follow-up remain available.

Directory filters and member selection controls have accessible names. Response
date filters keep **Submitted from** and **Submitted to** labels visible. Saved
response views have a persistent **View name** label, support Enter to save,
and have named dialog and close controls.

Read [Members directory](/product/members-directory),
[Member profiles](/product/member-profiles), and [Forms](/product/forms) for the
updated steps.


# Access requests include a security check
Source: https://docs.thefaithapp.com/changelog/2026-10-06-access-requests-security-check

Complete a security check before requesting access and retry without losing your entered details.

The public **Request access** form now includes a **Security check** to help
keep automated submissions out of the review queue and reduce unwanted request
emails.

The check fits the form width on desktop and phones, with comfortable spacing
above the send button.

Complete the check before sending your request. If it expires or cannot finish,
use **Retry security check**; your entered church and contact details stay on
the page. You can book a demo call if the check remains unavailable.

Access requests still go through review before an account invitation is sent.
Read [Client onboarding](/product/client-onboarding) for the request and review
steps.


# Free tools for church messages and visitor follow-up
Source: https://docs.thefaithapp.com/changelog/2026-10-06-free-church-tools

Personalize church text messages and prepare a visitor welcome plan without creating an account.

TheFaithApp has two new [free church tools](https://thefaithapp.com/tools) for
the work already on your team’s desk:

* **Church SMS templates:** personalize eight messages for welcomes, events,
  volunteers, care, small groups, and giving thanks. Copy one message or download
  the templates you choose.
* **Church visitor follow-up planner:** prepare a first-week welcome plan with
  editable text or email drafts, a follow-up owner, and practical team notes.

Both tools work without an account. Your drafts stay in the page until you copy
or download them; the tools do not send messages or schedule follow-up.

Read [Free church tools](/product/free-church-tools) for the steps.


# Follow free tools through church onboarding
Source: https://docs.thefaithapp.com/changelog/2026-10-06-free-tool-conversions

See consented tool visits alongside access requests, approvals, account creation, and church activation.

Super Admins can now use **Client Onboarding → Tool to activation** to see
requests linked to the free church SMS templates and visitor follow-up planner.
The table separates requests, approvals, created accounts, and activated
churches, covering the last 90 days independently of the request list filters.

The last free tool visited is linked only when the visitor accepts analytics
and separately permits attribution on their access request. No message drafts,
form answers, or entered church details are included in tool attribution.
Requests without a consented tool visit appear under **Other or unattributed**.

Approvals count invited churches, churches completing onboarding, and created
accounts. Qualification alone is not approval. Activation still requires a
member, a published public form, and a completed non-spam public response.

Optional attribution expires after 90 days. Super Admins can remove it on consent
withdrawal while preserving the application and account. Existing requests are
not attributed retrospectively.

Read the [client onboarding guide](/product/client-onboarding) for the full process.


# Put your first church workflow to work
Source: https://docs.thefaithapp.com/changelog/2026-10-07-first-response-follow-up

Follow dashboard setup through a real form response and a saved next step.

The dashboard setup guide now continues past publishing a form. Main church
administrators can follow five saved steps: church details, a member, a public
form, a completed public response, and a recorded follow-up.

When the first response arrives, the guide points to **Forms → Responses**.
Assign a staff member and due date, then select **Save follow-up**, or save a
finished response as **Completed**. Spam and unfinished responses do not count
toward the guide.

The reminder returns to unfinished setup tasks afterward. Completed churches
retain a link to review responses. Recording a next step does not send messages
or carry out follow-up for your team.

Read [Client onboarding](/product/client-onboarding) for the full steps.


# Connect calendars and church automations
Source: https://docs.thefaithapp.com/changelog/2026-10-08-connected-calendars-and-automations

Connect Google or Outlook schedules and use Zapier or Make through invitation access.

> [!NOTE]
>
> Calendar and automation features are live. **Zapier is available by
> invitation** and remains private; its public listing is deferred. **Make is
> also available by invitation**, with public directory review pending. You
> can use both integrations now through their invitations.

Connected calendars add Google and Outlook authorization, calendar choice,
schedule updates, cancellations, and sync history alongside existing private
calendar subscriptions. Church teams manage shared calendars from Events;
members manage their personal schedule from the Volunteer Hub.

Registered events stay in members' calendars even when an early morning or
late evening event falls on a different date in UTC.

Calendar connections can now finish authorization and load available calendars
reliably. If a connection stopped after sign-in, choose **Check authorization**
to continue without signing in again.

Members who opt into serving sync can receive real calendar invitations from
their church's connected organizer account. Declining those invitations updates
their serving response. Personal appointment copies provide a TheFaithApp
response link when organizer invitations are unavailable.

Serving response links now open a member page with the role, date, time,
timezone, and location. Members can accept or decline without a staff account;
declining requires a reason shared with their serving leader. Opening a link
does not record a response. Existing links keep their original expiry, and
unavailable invitations show guidance to the member's schedule or serving leader.

**Platform > Developers** adds scoped automation keys, supported triggers and
actions, and recent workflow outcomes for Zapier and Make. Keys can expire or
be revoked. Repeated actions reuse their recorded outcome so a provider retry
does not repeat the same work.

Automation connections accept only TheFaithApp's service addresses, so a
mistyped destination cannot receive your automation key.

Creating an automation key now honors the expiration shown in the form. The
date remains in place if a request fails, so retrying preserves the intended
expiry.

Creating a new person through Zapier or Make now succeeds reliably. Updating
someone already in the church keeps their original source, and matching email
addresses continue to reuse the existing person.

Custom connector setup now shows the correct way to authenticate an automation
key.

**Return Success** gives Zapier and Make workflows a final test action that
does not change church records. Current versions check that the connected
account is still authorized; older private Zapier versions return success
locally.

The current Zapier invitation version uses the live church connection and
clearer person, donation, date, and registration fields. Trigger setup samples
match the fields delivered when the workflow runs.

Background retry timing has been corrected to give long-running work time to
finish before it is attempted again. Mobile version **4.0.17** is prepared for
release validation with the member calendar connection flow.

Make's advanced **Make an API call** option supports authenticated requests
for workflows that need additional API operations. Its connection uses your
live church, so action tests can change records or send messages. Use suitable
test records, or choose **Return Success** to check the connection without
changing church records. Public directory approval remains pending.

Open **Platform > Developers > Set up Zapier** or **Set up Make** to access
the invitation. If an invitation is unavailable, contact
[support@thefaithapp.com](mailto:support@thefaithapp.com) with your church name
and preferred provider. Review uncertain message deliveries before trying
again. Read [Events and Volunteers](/product/events-and-volunteers) and
[Platform, Access and Integrations](/product/platform-access-integrations)
for setup and troubleshooting.


# Review and copy free church resources
Source: https://docs.thefaithapp.com/changelog/2026-10-10-free-tools-first-result

See example drafts first, then copy complete templates or a visitor plan with your edits.

The [free church tools](https://thefaithapp.com/tools) let you choose **Review
example drafts** before adding any details. Personalize the examples when useful,
then review the drafts with your team.

Choose **Copy templates** to keep the messages currently shown, or **Copy plan**
to keep a complete visitor follow-up plan. Copying includes your draft edits and
review reminders; the plan also includes timing, the follow-up owner, team notes,
and email subjects when selected. Downloads keep the same complete text.

If automatic copying is unavailable, the tool shows selectable text for manual
copying. Both tools remain free without an account and prepare drafts without
sending messages or scheduling follow-up.

Read [Free church tools](/product/free-church-tools) for the steps.


# Find a starting plan from four capacity needs
Source: https://docs.thefaithapp.com/changelog/2026-10-10-pricing-plan-finder

Compare member, administrator, branch, and monthly campaign counts on the public pricing page.

The [pricing page](https://thefaithapp.com/pricing) includes **Find a starting
plan**. Enter expected member profiles, staff administrator accounts, branch
records, and combined email and SMS campaigns scheduled or sent each calendar
month to see the lowest published plan covering those four counts.

Enterprise results include its member-block pricing. Counts beyond the published
administrator, branch, or campaign allowances show that no published tier matches.
Review the full comparison for other features and allowances; base-plan prices
do not include optional add-ons or external services.

Counts stay in the page. The finder does not submit an access request, create an
account, or change a subscription.

Read [Find a starting plan](/product/pricing-plan-finder) for the steps and scope.


# Inspect product screenshots in a larger view
Source: https://docs.thefaithapp.com/changelog/2026-10-10-product-screenshot-viewer

Enlarge existing product screenshots while exploring TheFaithApp without an account.

Public product pages include **Enlarge screenshot** beside their screen
examples. Open an image in a larger view to inspect the existing screenshot
without signing in.

Choose **View original size** to inspect details and scroll around the image,
or **Fit to screen** to see the whole screenshot. **Open full image** opens
the image directly.

Choose **Close** or press **Escape** to return to the page and the link you
opened. If the viewer is unavailable, **Enlarge screenshot** opens the original
image.

The screenshots are product examples, not an interactive dashboard. Read
[Client onboarding](/product/client-onboarding#explore-before-requesting-access)
for public exploration and reviewed access.


# Keep edited free-tool drafts while personalizing
Source: https://docs.thefaithapp.com/changelog/2026-10-12-free-tools-keep-edited-drafts

Change details or switch formats without replacing the wording your team has edited.

The [free church tools](https://thefaithapp.com/tools) keep edited messages while
you change details. Message text and email subjects you have not edited continue
to update. Review your retained wording after changing names, dates, links, or
opt-out instructions.

The visitor follow-up planner keeps separate text and email drafts, including
edited email subjects. Switching formats returns to your edits for that format,
and edited team tasks stay the same in both formats.

Choose **Restore generated draft** on a card to return to wording based on the
latest details. This restores both the subject and message for an email, or the
text of a team task. **Reset details** asks you to confirm before clearing
edited drafts, subjects, and tasks across both formats.

Copy or download your final version before reloading or leaving the page. These
tools prepare drafts without saving them, sending messages, or scheduling
follow-up.

Read [Free church tools](/product/free-church-tools) for the steps.


# Clearer cookie choices on the website
Source: https://docs.thefaithapp.com/changelog/2026-10-14-website-cookie-controls

Choose optional cookies without a banner covering page links or buttons.

The website's cookie notice now sits above the page content, so it does not
cover links, forms, or buttons on phones and larger screens.

Use **Cookie settings** in the footer to reopen the notice. The page brings the
choices into view, and returns you to the settings button after you choose.
Optional analytics and advertising measurement still stay off until you accept.

Website browsing also has stronger connection and script protections, while
existing forms, product guides, and video previews remain available.


# More reliable website request tracking
Source: https://docs.thefaithapp.com/changelog/2026-10-15-content-signup-tracking

Keep access requests usable when optional analytics or browser storage is unavailable.

An optional analytics failure no longer interrupts access requests or hides their
confirmation. Visitors can also change cookie choices when a measurement service
is unavailable.

After accepting optional cookies, the current article is counted once for that
page visit. Earlier clicks and scrolling are not replayed.

Campaign labels on the current tagged link can still accompany an access request
when optional browser storage is blocked. Both optional cookie acceptance and the
separate request-form choice are required. Earlier visits may remain unattributed.

An access request still requires review; it is separate from account creation,
church activation and payment. Read the [onboarding guide](/product/client-onboarding)
for the next steps.


# Clearer devotional notification tracking
Source: https://docs.thefaithapp.com/changelog/2026-10-15-devotional-notification-tracking

Distinguish push-provider acceptance from app-reported devotional receipt and taps.

Devotional notifications now have a separate record for each church-local day.
Repeated scheduler checks do not queue the same occurrence again.

In **Analytics → Notifications**, a devotional counts as sent when the push
provider accepts it. Delivery, open, and click totals require separate app
reports. These totals describe occurrences with a reported event, not the number
of members reached. Devotional topic sends remain in the all-platform view.

Missing reports leave the outcome unconfirmed. Background delivery is not
comprehensively measured, and older app versions may omit tap reports. Earlier
sends are not reconstructed or replayed by this change.

Read the [notification analytics guide](/product/analytics#notification-analytics)
before interpreting the totals.


# Keep your place during invited account setup
Source: https://docs.thefaithapp.com/changelog/2026-10-16-invitation-setup-keyboard-focus

Move between setup steps and correct invalid fields with clearer keyboard focus.

**October 16, 2026**

Invited church administrators can keep their place while completing account setup.

* **Next Step** and **Previous** move keyboard focus to the newly opened step.
* If a step needs a correction, focus moves to its first invalid field.
* Returning to an earlier step keeps the values you entered while the page stays open.

Account setup still requires a private invitation. The church logo remains optional.

[Complete invited account setup](/product/client-onboarding#send-a-private-invitation)


# Steadier website loading on phones
Source: https://docs.thefaithapp.com/changelog/2026-10-16-steadier-website-loading

See cookie choices above the page content and download a smaller homepage preview.

**October 16, 2026**

The website resolves whether to show its cookie notice before the page content
appears. The notice stays above links and forms, and a saved choice keeps it
hidden. Use **Cookie settings** in the footer to review your choice again.

The homepage dashboard preview also offers smaller images for phone screens,
with the original image available as a fallback.

Optional analytics and advertising measurement still stay off until you accept.


# Chat with TheFaithApp support
Source: https://docs.thefaithapp.com/changelog/2026-10-16-support-chat

Ask product questions on the website and get help inside the dashboard.

**October 16, 2026**

Start a support conversation from the bottom-right chat button on the
TheFaithApp website or in the signed-in dashboard.

* Ask about plans or church setup from the website without creating an account.
* Get help in the dashboard with your admin account and church recognized.
* Keep form buttons clear: chat stays hidden while drawers and dialogs are open.
* Use chat in place of the old Support page, menu item, and inquiry form.
* Use the website’s direct email fallback if chat cannot load.

Leave a message if the team is away; an immediate reply is not guaranteed.

[Get help with the dashboard](/product/dashboard-and-internal-tools#support-chat)


# A clearer next action for visitor follow-up
Source: https://docs.thefaithapp.com/changelog/2026-10-16-visitor-personal-follow-up

Plan one personal response from the visitor overview, with contact permission beside the task fields.

**October 16, 2026**

Visitor Inbox now gives staff a clearer route from a new guest response to one
personal follow-up task.

* Open a visitor and choose **Add a follow-up task** from the top of
  **Overview**, or **Review follow-up tasks** when work is already open.
* Check the preferred contact method and permission for email, text, and phone
  both before opening a task and while planning it.
* Choose a staff owner, one useful next action, and a due time using the existing
  task form, with clearer field labels for keyboard and assistive technology.

The shortcut respects **No follow-up** choices and closed or converted
journeys. A saved task is an internal reminder: it does not send a message or
prove contact happened.

[Follow up with one visitor](/product/new-visitor-journey#6-follow-up-with-one-visitor)


# Keep invited account setup consistent
Source: https://docs.thefaithapp.com/changelog/2026-10-17-consistent-invited-account-setup

Complete invited registration once and preserve the account when an older review action finishes.

**October 17, 2026**

**Complete Registration** now starts processing immediately and prevents
repeated clicks from submitting the same invitation twice. If setup fails,
entered details stay available for another attempt.

Once a church account has been created, an older review action cannot decline
the request, revoke the invitation, or send another account setup invitation.
Refresh the review panel to see the latest status.

Account creation, setup activation and actual church use remain separate.
Optional campaign attribution can still be removed without deleting the
request or church account.


# Steadier prayer loading and church search
Source: https://docs.thefaithapp.com/changelog/2026-10-17-mobile-prayer-and-church-search

Recover from a failed Prayer Community refresh and keep church searches focused on the current query.

**October 17, 2026**

Mobile version **4.0.19** handles a failed Prayer Community refresh without
leaving a request error unhandled. Previously loaded prayer content stays
available, and you can tap **Refresh** to try again.

Searching for a participating church preserves punctuation in its name,
including `&` and `#`. Results from an older search no longer mix with the
current search, including while loading another page.

Install the update when it is available in your app store.


# Cleaner private email links
Source: https://docs.thefaithapp.com/changelog/2026-10-17-private-email-link-sessions

Continue private account setup, password reset and administrator sign-in from a cleaner page address.

**October 17, 2026**

Private invitation, password-reset and administrator sign-in links now open a
cleaner page address while keeping the original email credential available for
the action it authorizes. Refreshing an active session still works, and separate
links can remain open in separate tabs.

If a secure link session becomes unavailable, reopen the original link from
your email. The original invitation's expiry and one-use rules still apply;
opening a page does not create an account or approve access.


# Compare enquiries and setup activity over matching dates
Source: https://docs.thefaithapp.com/changelog/2026-10-19-dated-acquisition-reporting

Separate consented search sources, exclude QA and compare dated enquiries, account creation and recorded activation.

The onboarding workspace now has **Acquisition activity** with a shared date
range and reporting time zone for saved enquiries, created accounts and first
recorded activations. Source and medium appear separately, including organic
and paid Google visits. Public applications are counted separately from manual
invitations.

Synthetic QA records are excluded. Reviewers can mark or unmark a request as
QA without changing its onboarding stage or removing its account.

Recognized search source and medium can accompany a request after both analytics
consent and the separate request-attribution choice. Earlier unknown sources
and activation dates are not guessed or filled in retrospectively.

Read [Client onboarding](/product/client-onboarding#compare-acquisition-activity)
for date definitions, QA controls and comparison limits.


# Safer text-to-give keyword setup
Source: https://docs.thefaithapp.com/changelog/2026-10-21-giving-keyword-controls

Keep Giving keywords separate from text-message subscription and help commands.

Giving Access now rejects built-in SMS control words, such as **START**, **STOP**,
and **HELP**, when creating or activating Giving keywords. Choose a distinct word,
such as **GIVE** or **BUILD**, for your giving link.

Existing keywords are not changed automatically. Delete an older reserved
keyword and create a distinct replacement, or deactivate it if its other details
are still valid. This does not unsubscribe anyone or change how SMS control
commands work.

Read [Text-to-Give Links](/product/giving-and-finance#text-to-give-links) before
publishing a keyword.


# Clearer member import history
Source: https://docs.thefaithapp.com/changelog/2026-10-21-member-import-history

Distinguish accepted preview rows from completed imports in the member directory.

Member import history now labels uncommitted preview rows as **Accepted
(preview)**, separately from historical **Imported** counts. This makes it easier
to distinguish validation results from saved directory records.

The history also identifies who uploaded the file. Completed and undone
migrations retain their historical imported counts.

Read [Validate before importing](/product/member-data-hygiene#validate-before-importing)
for the preview and commit steps.


# Clearer SMS draft segment estimates
Source: https://docs.thefaithapp.com/changelog/2026-10-21-sms-draft-segment-estimates

Estimate GSM-7 and Unicode segments in campaign and template drafts, with clearer limits before sending.

SMS campaign and template editors now account for Unicode text, emoji and
symbols that use extra space when estimating message segments.

The campaign review shows estimated draft segments instead of a fixed dollar
amount. Personalized values, unsubscribe links and added opt-out wording can
change the finished message. Your provider's sender settings and charges still
apply.

Read [Creating an SMS campaign](/product/marketing#check-the-draft-segment-estimate)
for what the estimate includes and what to check before sending.


# Safer text-to-join keyword setup
Source: https://docs.thefaithapp.com/changelog/2026-10-22-join-keyword-controls

Keep church join keywords separate from text-message control commands.

Text-to-join setup now rejects built-in SMS control words, such as **START**,
**STOP**, and **HELP**, when creating or activating join keywords. Choose a
distinct word, such as **JOIN** or **PRAY**, for church text updates.

Existing keywords are not changed automatically. An older reserved keyword can
still be paused, and its name or confirmation reply can be maintained. Editing
those details does not replace its text word or change its active state.
Create a distinct replacement before sharing new joining instructions.

This does not change subscription or help commands. Your SMS provider may reserve
additional words.

Read [SMS Inbox and Text-to-Join](/product/engagement-and-communication#sms-inbox-and-text-to-join).


# Clearer access errors in mobile giving
Source: https://docs.thefaithapp.com/changelog/2026-10-23-giving-sdk-020

Flutter and React Native Giving SDKs 0.2.0 help apps offer the right recovery for sign-in, plan access and permission failures.

# Clearer access errors in mobile giving

Giving SDK version 0.2.0 is now available for
[Flutter](https://pub.dev/packages/thefaithapp_giving/versions/0.2.0) and
[React Native and Expo](https://www.npmjs.com/package/@thefaithapp/giving-react-native/v/0.2.0).

Apps can distinguish an expired member sign-in from a church plan that does
not include SDK access, or another permission failure. This helps the app offer
the right next step: sign in again, ask the church administrator to review
plan access, or check permission for the requested action.

The SDKs also expose the subscription ID when a PayPal recurring checkout
response provides one.

When upgrading from 0.1.0, update custom error handlers for the new plan-access
and permission cases. React Native apps that build their own checkout objects
or test fixtures also need to include the nullable PayPal subscription ID.
The auth SDK dependency remains on 0.1.x.

Follow the updated setup and upgrade guidance:

* [Flutter Giving SDK](/api-reference/flutter-giving-sdk#handle-access-failures)
* [React Native Giving SDK](/api-reference/react-native-giving-sdk#handle-access-failures)


# More reliable mobile giving and recurring gifts
Source: https://docs.thefaithapp.com/changelog/2026-10-24-mobile-giving-and-recurring-gifts

Clearer mobile checkout, safer recurring-payment recovery, and updated Android setup guidance.

# More reliable mobile giving and recurring gifts

Mobile giving forms keep checkout controls reachable while entering an amount,
load giving options together, and complete PayPal approvals using the correct
return path.

Recurring Stripe gifts keep their payment records and fund allocations when a
billing request is retried. General gifts without a selected fund can renew,
and failed-payment notifications no longer add another retry or change another
church's recurring gift.

A payment remains pending until the provider confirms it. Recurring options
appear only when automatic payments are enabled for the connected provider.

The [Flutter](/api-reference/flutter-giving-sdk) and
[React Native](/api-reference/react-native-giving-sdk) integration guides now
cover the Android release setup needed by the native payment libraries.


# Mobile SDK patch updates
Source: https://docs.thefaithapp.com/changelog/2026-10-24-sdk-patch-releases

Flutter Giving 0.2.1, React Native Giving 0.2.1 and React Native Auth 0.1.1 are available.

# Mobile SDK patch updates

The latest mobile SDK patches are available:

* [Flutter Giving 0.2.1](https://pub.dev/packages/thefaithapp_giving/versions/0.2.1)
* [React Native Giving 0.2.1](https://www.npmjs.com/package/@thefaithapp/giving-react-native/v/0.2.1)
* [React Native Auth 0.1.1](https://www.npmjs.com/package/@thefaithapp/auth-react-native/v/0.1.1)

Giving forms load options together and keep payment controls usable on phones.
Recurring choices follow the connected provider's availability, and PayPal
approvals return to checkout reliably. The React Native packages also include
updated development tooling and security checks.

Use the [Flutter](/api-reference/flutter-giving-sdk) or
[React Native](/api-reference/react-native-giving-sdk) guide to update your app.
The access-error migration guidance for Giving 0.2.0 still applies when upgrading
from 0.1.0. Flutter Auth remains at 0.1.0.


# Changelog
Source: https://docs.thefaithapp.com/changelog/index

Product updates, improvements, and releases across TheFaithApp.

Follow the latest product updates across TheFaithApp. Each entry highlights what changed, why it matters, and where the update shows up in the platform.

## Latest Updates

> **[Mobile SDK patch updates](/changelog/2026-10-24-sdk-patch-releases)**
>
> **October 24, 2026**
>
> Update to Flutter Giving 0.2.1, React Native Giving 0.2.1 and React Native Auth 0.1.1 for the latest checkout and security fixes.

> **[More reliable mobile giving and recurring gifts](/changelog/2026-10-24-mobile-giving-and-recurring-gifts)**
>
> **October 24, 2026**
>
> Keep mobile checkout usable and recurring gift recovery accurate, with updated Android setup guidance.

> **[Clearer access errors in mobile giving](/changelog/2026-10-23-giving-sdk-020)**
>
> **October 23, 2026**
>
> Flutter and React Native Giving SDKs 0.2.0 distinguish sign-in, plan access and other permission failures.

> **[Safer text-to-join keyword setup](/changelog/2026-10-22-join-keyword-controls)**
>
> **October 22, 2026**
>
> Reject built-in SMS control words when creating or activating text-to-join keywords.

> **[Safer text-to-give keyword setup](/changelog/2026-10-21-giving-keyword-controls)**
>
> **October 21, 2026**
>
> Reject built-in SMS control words when creating or activating Giving keywords.

> **[Clearer member import history](/changelog/2026-10-21-member-import-history)**
>
> **October 21, 2026**
>
> Distinguish accepted preview rows from imported members and see who uploaded the file.

> **[Clearer SMS draft segment estimates](/changelog/2026-10-21-sms-draft-segment-estimates)**
>
> **October 21, 2026**
>
> Estimate draft SMS segments with Unicode and symbol handling, and review personalization and provider limits.

> **[Compare enquiries and setup activity over matching dates](/changelog/2026-10-19-dated-acquisition-reporting)**
>
> **October 19, 2026**
>
> Separate organic and paid sources, exclude QA and compare dated enquiries, account creation and recorded activation.

> **[Cleaner private email links](/changelog/2026-10-17-private-email-link-sessions)**
>
> **October 17, 2026**
>
> Continue private email-link actions from a cleaner address, with recovery from the original email if a session is unavailable.

> **[Steadier prayer loading and church search](/changelog/2026-10-17-mobile-prayer-and-church-search)**
>
> **October 17, 2026**
>
> Recover from failed prayer refreshes and keep church search results tied to the current query in mobile version 4.0.19.

> **[Keep invited account setup consistent](/changelog/2026-10-17-consistent-invited-account-setup)**
>
> **October 17, 2026**
>
> Complete invited registration once and preserve accepted accounts when an older review action finishes.

> **[Steadier website loading on phones](/changelog/2026-10-16-steadier-website-loading)**
>
> **October 16, 2026**
>
> Resolve cookie-notice visibility before page content appears and use smaller homepage previews on phones.

> **[Chat with TheFaithApp support](/changelog/2026-10-16-support-chat)**
>
> **October 16, 2026**
>
> Chat on the website or dashboard, with the old Support page removed and drawer form buttons kept clear.

> **[Keep your place during invited account setup](/changelog/2026-10-16-invitation-setup-keyboard-focus)**
>
> **October 16, 2026**
>
> Move keyboard focus to the newly opened setup step or its first invalid field.

> **[A clearer next action for visitor follow-up](/changelog/2026-10-16-visitor-personal-follow-up)**
>
> **October 16, 2026**
>
> Plan one personal response from the visitor overview, review open tasks first, and check contact permission while planning the next action.

> **[More reliable website request tracking](/changelog/2026-10-15-content-signup-tracking)**
>
> **October 15, 2026**
>
> Keep access requests usable through optional analytics failures and preserve current-link labels when browser storage is unavailable.

> **[Clearer devotional notification tracking](/changelog/2026-10-15-devotional-notification-tracking)**
>
> **October 15, 2026**
>
> Distinguish push-provider acceptance from app-reported devotional receipt and taps.

> **[Clearer cookie choices on the website](/changelog/2026-10-14-website-cookie-controls)**
>
> **October 14, 2026**
>
> Choose optional cookies without covering page controls, and reopen your choices from the footer.

> **[Keep edited free-tool drafts while personalizing](/changelog/2026-10-12-free-tools-keep-edited-drafts)**
>
> **October 12, 2026**
>
> Keep edited messages, email subjects, and team tasks while changing details or switching formats, with explicit restore and reset controls.

> **[Inspect product screenshots in a larger view](/changelog/2026-10-10-product-screenshot-viewer)**
>
> **October 10, 2026**
>
> Enlarge existing product screenshots, inspect details, and return to the page with keyboard-friendly controls.

> **[Find a starting plan from four capacity needs](/changelog/2026-10-10-pricing-plan-finder)**
>
> **October 10, 2026**
>
> Compare member, administrator, branch, and monthly campaign counts before reviewing the full plan allowances.

> **[Review and copy free church resources](/changelog/2026-10-10-free-tools-first-result)**
>
> **October 10, 2026**
>
> Read examples before adding details, then copy complete templates or a visitor plan with your edits and team notes.

> **[Connect calendars and church automations](/changelog/2026-10-08-connected-calendars-and-automations)**
>
> **October 8, 2026**
>
> Connect Google or Outlook schedules and church workflows with scoped keys.
> Zapier stays private and is available by invitation. Make is also available
> by invitation while its public directory review is pending.

> **[Put your first church workflow to work](/changelog/2026-10-07-first-response-follow-up)**
>
> **October 7, 2026**
>
> Follow setup through a completed public response and a saved follow-up owner and due date, or a Completed status.

> **[Follow free tools through church onboarding](/changelog/2026-10-06-free-tool-conversions)**
>
> **October 6, 2026**
>
> See consented free-tool visits alongside requests, approvals, account creation, and church activation, with 90-day retention and removal on consent withdrawal.

> **[Free tools for church messages and visitor follow-up](/changelog/2026-10-06-free-church-tools)**
>
> **October 6, 2026**
>
> Personalize church SMS templates and prepare a visitor welcome plan with editable messages, team responsibilities, and free downloads. No account needed.

> **[Access requests include a security check](/changelog/2026-10-06-access-requests-security-check)**
>
> **October 6, 2026**
>
> Complete a security check before requesting access and retry without losing your entered details, helping keep automated submissions out of the review queue.

> **[Read member cards and choose a useful follow-up method](/changelog/2026-10-05-member-directory-and-follow-up)**
>
> **October 5, 2026**
>
> Read member names and actions on phones, use contact-aware follow-up defaults, and identify response date boundaries and saved views more easily.

> **[Open product menus with your keyboard](/changelog/2026-10-04-keyboard-product-menus)**
>
> **October 4, 2026**
>
> Open collapsed menus with Enter or Space, move between choices with arrow keys, and return focus with Escape.

> **[Save members first and follow up clearly](/changelog/2026-10-03-member-invitations-and-follow-up)**
>
> **October 3, 2026**
>
> Choose when to invite a member, correct missing contact details on mobile, and explore an assigned demo response.

> **[A smoother first church journey](/changelog/2026-10-03-first-church-journey)**
>
> **October 3, 2026**
>
> Continue from signup into the dashboard, save form settings reliably, and collect usable visitor follow-up details.

> **[Connect a new or existing Stripe account](/changelog/2026-10-02-connect-existing-stripe-account)**
>
> **October 2, 2026**
>
> Select an existing Standard account or create a new one through Stripe, with safer setup and disconnects.

> **[A calmer dashboard for daily work](/changelog/2026-09-26-focused-dashboard)**
>
> **September 26, 2026**
>
> Find daily priorities first, with compact setup guidance and expandable reports.

> **[From access request to an active church](/changelog/2026-09-26-acquisition-and-activation)**
>
> **September 26, 2026**
>
> Add members directly, recover from connection failures, and measure setup progress separately from account creation.

> **[Clearer public forms and navigation](/changelog/2026-09-25-focused-public-forms)**
>
> **September 25, 2026**
>
> Responsive church navigation keeps Give within the page, with compact headers and clearer public forms.

> **[A clearer start for your church](/changelog/2026-09-25-church-setup-guide)**
>
> **September 25, 2026**
>
> Start without a logo and follow three practical dashboard setup steps, with progress based on saved data.

> **[A People group at the top of the sidebar](/changelog/2026-09-17-people-group-in-the-sidebar)**
>
> **September 17, 2026**
>
> Dashboard, Members, Visitor Inbox, Pastoral Care, Donors & Giving, Households, Groups, and Communications now sit together in one sidebar group that opens by default after sign-in.

> **[Event pages: add to calendar, share, and registration options](/changelog/2026-09-16-event-page-calendar-share-and-options)**
>
> **September 16, 2026**
>
> Public event pages gain Google Calendar and Apple/Outlook calendar links, a share button with copy-link feedback, and optional registration checkboxes such as "Bring a dish" that you define per event.

> **[Public devotionals page: topic filters, email sign-up, and the app](/changelog/2026-09-16-devotionals-page-topics-and-email-signup)**
>
> **September 16, 2026**
>
> Visitors can filter devotionals by topic, subscribe by email to get new devotionals from the church, and jump to the mobile app from the same page.

> **[Pastoral notes are now only visible to pastoral staff](/changelog/2026-09-16-pastoral-notes-stay-with-pastoral-staff)**
>
> **September 16, 2026**
>
> A member note marked "Visible to pastoral staff" is hidden from admins without the Pastoral Care permission, in the notes list, the activity timeline, and when deleting; the toggle only appears for staff who can use it.

> **[Assign a follow-up to any member](/changelog/2026-09-16-assign-follow-ups-to-members)**
>
> **September 16, 2026**
>
> From a member profile, assign a call, text, email, or visit to a colleague with a due date, mark it done with an outcome, and see it in the dashboard follow-up list and the attention bell.

> **[Add members to a group straight from the Members list](/changelog/2026-09-16-add-members-to-a-group-in-bulk)**
>
> **September 16, 2026**
>
> Tick any number of members, choose a community group, and add them all at once; anyone already in the group or beyond its capacity is reported rather than duplicated.

> **[Every public church page shares one header and footer](/changelog/2026-09-16-public-pages-shared-header)**
>
> **September 16, 2026**
>
> Visit, Connect, Devotionals, Campaigns, Outreach, Give, and Prayer Request now carry the same navigation, a Give button, and a footer with the church's details.

> **[The dashboard now opens with people](/changelog/2026-09-16-people-first-dashboard)**
>
> **September 16, 2026**
>
> New visitors, follow-ups due today, open care cases, and this month's gifts sit at the top, with today's follow-up list, what needs attention, recent activity, and a giving trend.

> **[Search everything from the header, and see what needs attention](/changelog/2026-09-16-search-and-attention-bell)**
>
> **September 16, 2026**
>
> A search box on every dashboard page finds members, visitors, care cases, and pages, and a bell shows overdue follow-ups, unowned or urgent care, profile changes, and new form responses.

> **[The Members list is now a working directory](/changelog/2026-09-16-members-directory-workspace)**
>
> **September 16, 2026**
>
> Saved views, filters for tags, groups, sign-in and giving, sortable columns, a column chooser, CSV export, and bulk tagging.

> **[Member profiles bring everything about a person together](/changelog/2026-09-16-member-profiles)**
>
> **September 16, 2026**
>
> Open any member to see their activity, giving, groups, household, and care in one place, and keep notes and tags on the record.

> **[Public forms load reliably on church websites](/changelog/2026-09-16-public-forms-load-reliably)**
>
> **September 16, 2026**
>
> Embedded and shared forms now open correctly when the church site and TheFaithApp run on different domains.

> **[Faster sermon series browsing](/changelog/2026-09-05-faster-mobile-sermon-series)**
>
> **September 5, 2026**
>
> Revisit sermon series and message lists with less waiting in the mobile app.

> **[Client onboarding is now invitation-only](/changelog/2026-09-03-client-onboarding-is-now-invitation-only)**
>
> **September 3, 2026**
>
> Churches can request access while Super Admins review fit and send secure, private account setup links.

> **[Churches control member AI access](/changelog/2026-08-31-churches-control-member-ai-access)**
>
> **August 31, 2026**
>
> Ask your church is now an explicit church-paid choice with administrator control and a per-member fair-use safeguard.

> **[Paid plans now have clear growth limits](/changelog/2026-08-31-paid-plans-have-clear-growth-limits)**
>
> **August 31, 2026**
>
> Standard, Large, and Enterprise now scale through published allowances instead of repeating unlimited access.

> **[Pricing makes product capacity clear](/changelog/2026-08-30-pricing-makes-product-capacity-clear)**
>
> **August 30, 2026**
>
> Church management remains free for small churches while every plan now shows its products, allowances, add-ons, and data guarantees.

> **[YouTube Live becomes an on-demand sermon](/changelog/2026-08-29-youtube-live-becomes-an-on-demand-sermon)**
>
> **August 29, 2026**
>
> Finished YouTube Live services can become on-demand sermons automatically after YouTube processes the recording.

> **[Member migrations preview every outcome before import](/changelog/2026-08-29-member-migrations-preview-before-commit)**
>
> **August 29, 2026**
>
> Move people from Planning Center, Breeze, Subsplash, Tithe.ly, or another CSV with provider-aware mapping, duplicate review, and a safe undo path.

> **[Private calendars stay useful and private](/changelog/2026-08-29-private-calendars-stay-private)**
>
> **August 29, 2026**
>
> Churches can share automatically updated Event and service schedules without exposing member details or internal planning notes.

> **[QuickBooks and Xero connect to balanced giving journals](/changelog/2026-08-29-giving-exports-balanced-accounting-journals)**
>
> **August 29, 2026**
>
> Finance teams can connect QuickBooks or Xero, select live church accounts, and safely send balanced journals with duplicate-safe corrections.

> **[AI Assistance keeps people in the loop](/changelog/2026-08-28-ai-assistance-keeps-people-in-the-loop)**
>
> **August 28, 2026**
>
> Members can ask source-grounded church questions while staff gain permission-aware drafts, search, and transcript cleanup suggestions.

> **[Church networks work together with clear boundaries](/changelog/2026-08-27-church-networks-work-together-with-clear-boundaries)**
>
> **August 27, 2026**
>
> Trusted churches can support plants, coordinate shared ministry, and reuse resources without merging their member data.

> **[Operations and facilities stay ready](/changelog/2026-08-27-operations-and-facilities-stay-ready)**
>
> **August 27, 2026**
>
> Churches can coordinate rooms, Sunday operations, equipment, safety, access, transport, weather decisions, and emergency readiness from one audited workspace.

> **[Outreach connects mission work and local presence](/changelog/2026-08-27-outreach-connects-mission-and-local-presence)**
>
> **August 27, 2026**
>
> Churches can coordinate mission participation, preparation, prayer, service partners, verified impact, and reviewed stories across staff, member, and public experiences.

> **[Giving distinguishes received gifts from payment attempts](/changelog/2026-08-26-giving-distinguishes-received-gifts-from-payment-attempts)**
>
> **August 26, 2026**
>
> Giving now combines trustworthy totals, receipts, statements, safe QR/NFC/text access, recurring recovery, finance operations, accounting mappings, granular permissions, and protected history.

> **[Volunteers serve with clarity and care](/changelog/2026-08-25-volunteers-serve-with-clarity-and-care)**
>
> **August 25, 2026**
>
> Churches can build healthy teams, publish safer schedules, close coverage gaps, prepare worship services, and give members one Volunteer Hub.

> **[Communications reach the right people](/changelog/2026-08-19-communications-reach-the-right-people)**
>
> **August 19, 2026**
>
> Churches can prepare segmented announcements, weekly briefs, emergency alerts, SMS conversations, semantic bulletins, and focused campaign seasons.

> **[Events turn invitations into participation](/changelog/2026-08-18-events-turn-invites-into-participation)**
>
> **August 18, 2026**
>
> Churches can publish recurring events, collect free or paid registrations, manage waitlists and attendee needs, send reminders, and check people in.

> **[Private promises return without surveillance](/changelog/2026-07-28-private-promises-return-without-surveillance)**
>
> **July 28, 2026**
>
> Members can gently revisit explicit goals and Rule of Life commitments while churches shape the invitation without seeing personal activity.

> **[Sabbath mode protects room to rest](/changelog/2026-07-28-sabbath-mode-protects-room-to-rest)**
>
> **July 28, 2026**
>
> Churches can shape Sabbath and retreat invitations while members privately mute church broadcasts for a chosen window.

> **[The church calendar changes the formation tone](/changelog/2026-07-28-church-calendar-changes-the-formation-tone)**
>
> **July 28, 2026**
>
> Churches can shape every season of the year, and members automatically receive the current tone, Scripture, and practices without being scored.

> **[Lament makes room without forcing answers](/changelog/2026-07-28-lament-makes-room-without-forcing-answers)**
>
> **July 28, 2026**
>
> Churches can shape biblical lament liturgies while private words stay off the server and optional wall offerings remain moderated and anonymous.

> **[Congregational fasts make room for every body](/changelog/2026-07-28-congregational-fasts-make-room-for-every-body)**
>
> **July 28, 2026**
>
> Churches can coordinate shared fasts with meaningful substitutions while members join without explaining their health or circumstances.

> **[Guided Examen lets private words go](/changelog/2026-07-28-guided-examen-lets-private-words-go)**
>
> **July 28, 2026**
>
> Churches can shape a gentle evening review while members know their encrypted private words will be permanently deleted on schedule.

> **[Daily Office prays across distance](/changelog/2026-07-28-daily-office-prays-across-distance)**
>
> **July 28, 2026**
>
> Churches can publish their own fixed-hour liturgies while members choose gentle local bells, pray offline, and sense anonymous live presence.

> **[Seasonal Rules of Life stay private](/changelog/2026-07-28-seasonal-rules-of-life-stay-private)**
>
> **July 28, 2026**
>
> Churches can shape prayerful seasonal rhythms while every member writes and revisits a private covenant without streaks or scores.

> **[Gifts find open serving needs](/changelog/2026-07-28-gifts-find-open-serving-needs)**
>
> **July 28, 2026**
>
> Churches can shape discernment instruments that keep member results private, invite trusted mentor affirmation, and connect strong gifts to real opportunities.

> **[Personal formation stays personal](/changelog/2026-07-28-personal-formation-stays-private)**
>
> **July 28, 2026**
>
> Members can follow private discipleship goals and keep encrypted class reflections while churches provide customizable starting points without reading private progress.

> **[Discipleship connects mentors and members](/changelog/2026-07-28-discipleship-connects-mentors-and-members)**
>
> **July 28, 2026**
>
> Churches can shape staff-led mentorship programs, pair members with mentors, and keep shared check-ins in one protected journey.

> **[Discipleship remembers every formation step](/changelog/2026-07-28-discipleship-remembers-every-formation-step)**
>
> **July 28, 2026**
>
> Members and church teams can review pathway history, preserve certificates, and begin new formation cycles without losing earlier progress.

> **[Discipleship turns classes into formation pathways](/changelog/2026-07-27-discipleship-turns-classes-into-formation-pathways)**
>
> **July 27, 2026**
>
> Churches can build customizable classes with lessons, quizzes, teachers, member progress, and verifiable completion certificates.

> **[Mobile giving SDKs are available for Flutter and React Native](/changelog/2026-07-25-mobile-giving-sdks-are-available)**
>
> **July 25, 2026**
>
> Developers can add authenticated general and campaign giving without placing payment-processing endpoints or provider secrets in their apps.

> **[Partner apps can offer confidential Pastoral Care](/changelog/2026-07-25-partner-apps-can-offer-pastoral-care)**
>
> **July 25, 2026**
>
> Church apps can add member-owned care requests, private follow-up preferences, life moments, and quiet days through the v1 API.

> **[Pastoral Care organizes rites, coverage, and preaching](/changelog/2026-07-25-pastoral-care-organizes-rites-coverage-and-preaching)**
>
> **July 25, 2026**
>
> Care teams can coordinate rite checklists, bounded caregiver handoffs, and dependable preaching plans.

> **[Prayer Rooms protect media during app switches](/changelog/2026-07-23-prayer-rooms-protect-media-during-app-switches)**
>
> **July 23, 2026**
>
> Microphones and cameras now stay off after a member leaves and returns to the app foreground.

> **[Prayer Rooms add an audio-only fallback](/changelog/2026-07-23-prayer-rooms-add-audio-only-fallback)**
>
> **July 23, 2026**
>
> Video-room members can reduce video data while keeping prayer audio, chat, and room controls available.

> **[Pastoral prayer protects confidential care](/changelog/2026-07-23-pastoral-prayer-protects-confidential-care)**
>
> **July 23, 2026**
>
> Members can share an encrypted prayer request with a smaller, permission-controlled pastoral team.

> **[Urgent prayer connects members to timely follow-up](/changelog/2026-07-23-urgent-prayer-connects-timely-follow-up)**
>
> **July 23, 2026**
>
> Members can privately ask leaders for timely prayer support while churches coordinate a safe, owned response.

> **[Prayer teams coordinate daily care](/changelog/2026-07-23-prayer-teams-coordinate-daily-care)**
>
> **July 23, 2026**
>
> Churches can organize verified prayer volunteers around safe daily lists, assignments, availability, and weekly email digests.

> **[Private prayer journals build a personal prayer rhythm](/changelog/2026-07-23-private-prayer-journals-and-reminders)**
>
> **July 23, 2026**
>
> Members can keep prayers private, record answered reflections, share when ready, and choose daily, weekly, or one-time reminders.

> **[Prayer requests add safer audience controls](/changelog/2026-07-23-prayer-requests-add-audience-controls)**
>
> **July 23, 2026**
>
> Members can share prayer requests with their church, a Community Group, or church leaders and retain control through editing and withdrawal.

> **[Handwrytten cards are ready for visitor follow-up](/changelog/2026-07-23-handwrytten-cards-are-ready-for-visitor-follow-up)**
>
> **July 23, 2026**
>
> Churches can connect Handwrytten and send consent-aware welcome cards from a visitor journey, with guarded sender setup, test or live review, and order tracking.

> **[Forms connects church intake to follow-up](/changelog/2026-07-21-forms-connect-intake-to-follow-up)**
>
> **July 21, 2026**
>
> Churches can build, publish, share, and embed flexible forms, then assign and complete every response from one organized inbox.

> **[React Native apps can use hosted sign-in](/changelog/2026-07-18-react-native-apps-can-use-hosted-sign-in)**
>
> **July 18, 2026**
>
> Developers can add hosted member sign-in to React Native and Expo apps without running a callback website.

> **[Flutter apps can plug into hosted sign-in](/changelog/2026-07-18-flutter-apps-can-plug-into-hosted-sign-in)**
>
> **July 18, 2026**
>
> Developers can register a Flutter app in Developer Access and use the new SDK to receive a member bearer token without hosting a callback website.

> **[Community coordination adds practical tools](/changelog/2026-07-17-community-coordination-tools)**
>
> **July 17, 2026**
>
> Members can use clearer employment help, a reviewed lending and medical-equipment library, synchronized ministry chats, and flexible quiet hours and push preferences.

> **[Community research starts with member consent](/changelog/2026-07-17-community-research-is-consent-first)**
>
> **July 17, 2026**
>
> Members can privately share interest in future community-support ideas while staff see only protected aggregate readiness.

> **[Donation drives now use Outreach Campaigns](/changelog/2026-07-17-donation-drives-use-outreach-campaigns)**
>
> **July 17, 2026**
>
> Staff can connect a reviewed Needs & Offers donation drive to an existing campaign, giving members one coordinated place to contribute.

> **[Community keeps groups and chat together](/changelog/2026-07-16-community-keeps-groups-and-chat-together)**
>
> **July 16, 2026**
>
> Members can return to their groups, discover new ones, and open linked discussions or announcements from one mobile Community experience.

> **[Welcome every new visitor with one connected journey](/changelog/2026-07-16-welcome-every-new-visitor-with-one-connected-journey)**
>
> **July 16, 2026**
>
> Guests can plan a visit or connect without an account while staff coordinate consent-aware follow-up, useful next steps, and optional physical welcome cards.

> **[Your church week now meets you on Home](/changelog/2026-07-14-your-church-week-now-meets-you-on-home)**
>
> **July 14, 2026**
>
> See personal commitments, useful next steps, group updates, saved sermon moments, and quick actions together on the mobile Home screen.

> **[Member Directory connects your church](/changelog/2026-06-27-member-directory-connects-your-church)**
>
> **June 27, 2026**
>
> Members can browse a privacy-first church directory, control what they share, and staff can manage households, approvals, and reminders.

> **[Prayer Rooms trial limits protect live room capacity](/changelog/2026-06-22-prayer-rooms-trial-limits-protect-live-room-capacity)**
>
> **June 22, 2026**
>
> Trial Prayer Rooms now default to smaller gatherings with monthly participant-minute metering before upgrading.

> **[Hosted member sign-in simplifies API access](/changelog/2026-06-19-hosted-member-sign-in-simplifies-api-access)**
>
> **June 19, 2026**
>
> External apps can now use TheFaithApp-hosted member sign-in instead of bringing their own Firebase credentials.

> **[Prayer Community adds a church prayer feed](/changelog/2026-06-17-prayer-community-adds-a-church-prayer-feed)**
>
> **June 17, 2026**
>
> Members can now share approved prayer requests, mark that they prayed, and follow up when prayers are answered.

> **[Prayer Rooms beta is ready for mobile testing](/changelog/2026-06-17-prayer-rooms-beta-is-ready-for-mobile-testing)**
>
> **June 17, 2026**
>
> Members can now create and join beta audio and video prayer rooms, use room controls, and give toward room goals.

> **[Chat attachments, voice notes, and sermon sharing are upgraded](/changelog/2026-06-13-chat-attachments-voice-notes-and-sermon-sharing-are-upgraded)**
>
> **June 13, 2026**
>
> Chat now supports richer image, PDF, voice note, and sermon attachment experiences across web and mobile.

> **[Chat conversations are easier to follow](/changelog/2026-06-12-chat-conversations-are-easier-to-follow)**
>
> **June 12, 2026**
>
> Chat now has better room lists, timeline grouping, search, presence, reply navigation, and group details.

> **[Chat rooms have stronger admin controls](/changelog/2026-06-11-chat-rooms-have-stronger-admin-controls)**
>
> **June 11, 2026**
>
> Admins can now manage room behavior with moderation, read states, mentions, reactions, and notification preferences.

> **[Sermon AI content is available in the external API](/changelog/2026-06-11-sermon-ai-content-is-available-in-the-external-api)**
>
> **June 11, 2026**
>
> Third-party apps can now read published sermon transcripts, chapters, insights, and translated transcript cues.

> **[Chat realtime is now powered by Firebase](/changelog/2026-06-10-chat-realtime-is-now-powered-by-firebase)**
>
> **June 10, 2026**
>
> Chat messages, typing states, and room updates now arrive faster across web and mobile.

> **[Sermon AI tools are now available](/changelog/2026-06-09-sermon-ai-tools-are-now-available)**
>
> **June 9, 2026**
>
> Generate reviewed sermon transcripts, chapters, insights, translations, quote cards, content drafts, and uploaded-video clips.

> **[App customization is now available to all admins](/changelog/2026-05-29-app-customization-is-now-available-to-all-admins)**
>
> **May 29, 2026**
>
> The app customization workspace is now open to all admins, without the earlier rollout gate.

> **[App customization is now available](/changelog/2026-05-15-app-customization-is-now-available)**
>
> **May 15, 2026**
>
> Design a branded mobile experience with your own theme, navigation, custom pages, reusable content blocks, live preview, and release controls.


# Getting Started
Source: https://docs.thefaithapp.com/index

Explore TheFaithApp guides for church administration, member care, content, and giving, plus API integration quickstarts and product release notes.

## TheFaithApp Documentation

Welcome to the unified documentation for TheFaithApp.

This workspace now combines:

* Product documentation for admins, church operators, and internal teams
* API documentation for mobile apps, partner apps, and other integrations
* Release notes and documentation updates

## Start Here

* Read [Authentication](/product/authentication) for the first admin login and account access flows
* Continue with [Dashboard and Internal Tools](/product/dashboard-and-internal-tools) for the everyday admin workspace
* Open [Forms](/product/forms) to build, publish, share, and embed church forms and manage response follow-up
* Use [Content Management](/product/content-management) for sermons, devotionals, public devotional pages, bulletins, categories, and streaming workflows
* Open [Church Operations](/product/church-operations) for members, branches, gatherings, and admin access management
* Open [Events and Volunteers](/product/events-and-volunteers) for events, registration setup, ministries, volunteer skills, and signup review
* Open [Giving and Finance](/product/giving-and-finance) for donations, recurring gifts, funds, public giving pages, payment providers, billing plans, and AI add-on billing
* Open [Outreach and Donor Management](/product/outreach-and-donor-management) for campaigns, donors, donor forms, campaign analytics, public campaign pages, and donor profile pages
* Open [Engagement and Communication](/product/engagement-and-communication) for prayer requests, notifications, chats, invitations, and member saved-item features
* Open [Marketing](/product/marketing) for Mailgun, Twilio, campaigns, templates, subscriber lists, and marketing dashboards
* Open [Analytics](/product/analytics) for engagement, content, demographics, cohorts, notification performance, app versions, custom metrics, and alerts
* Open [Settings, Branding, and App Customization](/product/settings-branding-and-customization) for church profile, socials, email, Firebase setup, white-label branding, domains, page branding, and mobile app design workflows
* Open [API Introduction](/api-reference/introduction) to start with the public `v1` API
* Track documentation changes in [Changelog](/changelog)

## Documentation Structure

### Getting Started

Use this section for onboarding flows, shared concepts, and platform orientation.

### Product Guides

Use these pages for real admin workflows in the dashboard, with steps, screenshots, prerequisites, and caveats.

### API Reference

Use the API reference when integrating with TheFaith mobile, third-party apps, or custom church experiences.

### Changelog

Use the changelog to track product-facing documentation updates and notable platform releases.


# Admin, Data and Governance
Source: https://docs.thefaithapp.com/product/admin-data-governance

Build reports, manage church resources, coordinate formal decisions, and protect sensitive governance work.

Admin, Data & Governance brings cross-church reporting, reusable resources,
formal decisions, policy records, and data stewardship into one
permission-controlled workspace. Members receive only resources and
acknowledgements deliberately published to them.

> [!WARNING]
>
> TheFaithApp supports accountable church administration. It does not replace
> your bylaws, safeguarding process, pastoral judgment, legal advice, records
> policy, or an independent response to serious allegations.

## Before You Start

1. Decide who may view administrative data, manage reports, lead governance,
   read confidential documents, review retention, or enter a sealed case.
2. Assign discipline cases and whistleblower channels by name. A general
   administrator does not receive those records automatically.
3. Confirm your quorum, voting, recusal, policy-approval, retention, and legal
   hold rules outside the app.
4. Publish only the resource version that members should rely on.
5. Run a sandbox preview and one test access review before using the workspace
   with live church records.

## Build Reports and Saved Views

Open **Admin, Data & Governance > Reports & Data**. Choose an available church
dataset, add multiple filters, select the columns you need, and preview the
result before saving it.

Saved reports keep the report definition rather than a copied result set.
Exports check current access each time they run. A scheduled export sends only
to an eligible staff recipient and skips someone whose access has since been
removed.

Use bulk change only after reviewing the exact candidate count and sample. The
confirmation expires, cannot silently widen to new records, and records an
audit entry. Sandbox previews show the likely audience and effects without
changing records or contacting a messaging provider.

## Add Church-Specific Fields

Create a custom field for a member, household, visitor, or volunteer record.
Choose its value type, audience, and sensitivity before recording values.
Choice fields accept only the configured choices, and sensitive values remain
protected from ordinary search and exports.

## Use Reviewed Form Templates

The Forms template library includes connect, baptism, membership, counseling,
prayer, volunteer, background-check consent, facility, room-booking,
benevolence, testimony, mission-trip, and event-waiver starting points.

Review the questions, audience, managers, consent wording, and follow-up action
before publishing. Background-check consent records consent only; it does not
order a paid check. Event waivers and other attestations remain tied to the
published form version the person actually reviewed.

## Publish a Resource Library

Use **Resource Library** for ministry handbooks, volunteer guides, sermon
discussion guides, policies, facility maps, training materials, worship files,
and youth permission documents.

Set the intended audience, sensitivity, tags, effective date, and whether an
acknowledgement is required. Publishing creates a dependable current version
without removing earlier version history. Member downloads and
acknowledgements are tracked against that version.

The unified search returns links to approved sermons, transcripts, events,
announcements, resources, and staff knowledge. It does not search private
prayer or pastoral text, safeguarding records, discipline cases,
whistleblower reports, financial account details, or child medical details.

## Run Meetings and Decisions

Create a board, elder, deacon, committee, or congregational meeting and add its
agenda, documents, decisions, and owned actions. The packet keeps these items
together for review.

For a motion, freeze the eligible roster, record recusals, choose the voting
method and threshold, then open and close the vote. The result explains quorum
and the eligible denominator. Generated minutes always remain a draft until a
person reviews and approves them.

Annual plans preserve purpose, outcomes, milestones, risks, and follow-up.
Meeting action items keep an owner and due date visible between meetings.

## Manage Policies, Covenants, and Standing

Adopt a versioned policy, bylaw, or membership covenant with its effective
date. Require acknowledgement where appropriate, and set a renewal period for
a covenant that must be reaffirmed.

The member **Church Resources** area shows only published standard resources,
policy acknowledgements, and that member's safe membership-standing summary.
It never includes internal standing reasons or confidential governance data.

## Protect Confidential Governance

Leadership documents require the confidential-governance permission.
Conflict-of-interest declarations record the statement and recusal needed for
an explainable decision.

Discipline and restoration cases are separately sealed and visible only to an
assigned person who also has the discipline permission. Linking the protected
case to its member allows an assigned leader to offer only its current status
through a separately consented Church Network care handoff. The case itself
remains sealed. The public reporting channel seals a concern for its fixed
recipients, excludes anyone named as an accused person, and sends a
content-free notification.

For immediate danger or suspected abuse, follow your church safeguarding plan
and local reporting or emergency requirements before recording administrative
follow-up.

## Review Retention and Access

Retention rules record how long a dataset should be kept and whether it needs
review, archive, or approved disposition. A legal hold prevents an eligible
record from being treated as ready for removal.

Start a permission review to freeze each staff member's effective access. The
reviewer records a keep, change, or remove decision and a reason for every
person. The review closes only when no decision remains pending.


# Admin Navigation
Source: https://docs.thefaithapp.com/product/admin-navigation

Start in the People group, then move between the TheFaithApp admin products and their feature menus.

# Admin Navigation

The admin sidebar starts with **People** and then lists the products:

* `People`
* `Church Management`
* `Giving`
* `Analytics`
* `Marketing`
* `Outreach Campaigns`
* `Children & Youth`
* `Operations & Facilities`
* `Discipleship`
* `Forms`
* `App Customization`

## People

People gathers the pages you use every day about the people in your church, in this order: **Dashboard**, **Members**, **Visitor Inbox**, **Pastoral Care**, **Donors & Giving**, **Households**, **Groups**, and **Communications**. It opens after sign-in and whenever you land on one of those pages from a link or a bookmark.

Every page in People also stays where it was. Members and Visitor Inbox are still under Church Management, Donors & Giving is the Giving dashboard, and Households and Groups open the matching tabs on the Members page. Which door you use makes no difference to what you see.

## Open a Product

1. Use the back arrow beside the group name at the top of the sidebar to see the product list, or click the TheFaithApp logo.
2. Select the product you want to use.
3. Choose a feature from that product's menu.

Selecting a product replaces the product list with its feature menu. This keeps unrelated tools out of the way while you work.

## Return to the Product List

Use the back arrow beside the product name at the top of the sidebar. Your current page stays open while the sidebar returns to the product list.

## Work With Nested Menus

Some features contain another level of options. For example, `Marketing` contains `Email Marketing` and `SMS Marketing`, while `Outreach Campaigns` contains `Donor Management`.

1. Select the feature with the right arrow.
2. Choose the page you need.
3. Use the back arrow to return one level at a time.

## Use the Collapsed Sidebar With a Keyboard

1. Press **Tab** to reach a product, such as **Forms**. The focused control has
   a visible outline.
2. Press **Enter** or **Space** to open its menu.
3. Use **Up Arrow** and **Down Arrow** to move between choices, then press
   **Enter** to open a page. For a nested menu, use **Right Arrow** to enter
   it and **Left Arrow** to return.
4. Press **Escape** to close the menu and return focus to its opener.

Hovering or clicking a product still opens its menu.

## Dashboards

The `/home` page is the people-first dashboard described in [Dashboard and Internal Tools](/product/dashboard-and-internal-tools); it is the **Dashboard** entry in People. The Church Management product has its own dashboard at `/church` with media, bulletin, and membership statistics.

## Forms

Admins with the `Manage Forms` permission can open `Forms`, then select
`All Forms` to view or create form drafts. `Donor Forms` remains under
`Outreach Campaigns` and is a separate workflow.

Read the [Forms guide](/product/forms) for creating, publishing, sharing, and
managing responses.

## Direct Links and Refreshing

When you open or refresh a feature URL, the sidebar opens the matching product and feature menu automatically. This lets bookmarked pages retain their navigation context.

## Notes

* The header search lists every page once, even the ones that appear in both People and Church Management. See [Search and the Attention Bell](/product/search-and-attention).
* Menu items can vary with your admin permissions.
* On smaller screens, open the menu from the header and follow the same product and feature structure.


# AI Assistance
Source: https://docs.thefaithapp.com/product/ai-assistance

Use source-grounded member answers, review-only staff drafts, and safer sermon tools without replacing pastoral judgment.

AI Assistance helps members find published church information and helps staff
prepare work for human review. It does not act as a pastor, send messages,
publish content, merge members, or assign volunteers on its own.

## Ask Your Church In The Member App

After a church activates the paid Digital Ministry Assistant add-on, a billing
administrator can enable member access from **Settings > Billing &
Subscription > Add-ons**. Members can then open **Connect** and select **Ask
your church** to ask about service times, campuses, parking, Events, kids
ministry, Community Groups, sermons, bulletins, and devotionals.

The answer is built from published information for the signed-in member's
church. Source chips under an answer show the church content used. When a
question cannot be verified from those sources, the assistant says so instead
of guessing.

An answer may offer a shortcut to Events, Sermons, Groups, Prayer, or Pastoral
Care. These shortcuts open the existing member experience; the assistant does
not register, submit, book, message, or change anything.

### Pastoral And Urgent Needs

The assistant is not a counselor, clinician, emergency service, or spiritual
authority. Questions that need personal pastoral judgment are redirected to a
person through Prayer or Pastoral Care. Someone in immediate danger should use
local emergency help rather than wait for an AI reply.

Member questions and answers are not kept as a server-side chat history. A
member can still see the current answer on the open screen until they leave it.

Member replies use the church's shared monthly allowance. Each member can ask
up to five questions per day so one person cannot use the whole church
allowance. The free AI reply trial remains for staff evaluation and is not
available through the member app.

## Use AI Chat As A Staff Copilot

Open **Church Management**, then **AI Chat**. Staff can use a suggested prompt
or ask in natural language to:

* Draft visitor follow-up or Volunteer encouragement messages.
* Summarize care history that the signed-in leader is already allowed to see.
* Suggest next-step pathways or Community Groups from current church records.
* Find members, Events, resources, visitors, Groups, duplicate candidates, or
  Volunteer schedule gaps.
* Draft Event descriptions, announcement copy, weekly engagement summaries,
  and ministry reports.

AI Chat keeps the permissions of each source workspace. Access to AI Chat does
not grant access to Members, Pastoral Care, Visitors, Groups, or Volunteer data
that the staff member could not otherwise open.

All generated messages and operational suggestions are drafts. Review them
before use. Sending, publishing, scheduling, merging, and assigning remain
deliberate actions in their normal product screens.

## Review Sermon Assistance

Sermon AI works from a reviewed transcript. It can prepare summaries,
discussion questions, small-group guides, social captions, newsletter
summaries, short devotionals, key quotes, scripture lists, and clip
suggestions.

While reviewing a transcript, select **Suggest cleanup** to see conservative
wording suggestions and uncertain passages. Applying a suggestion only updates
the open editor. A staff member must still review and save the transcript; the
assistant never overwrites it automatically.

Generated sermon content should remain faithful to the reviewed transcript.
Review every quotation, scripture reference, and factual claim before sharing
or publishing it.

## Availability

AI Assistance uses the existing **Digital Ministry Assistant** add-on and its
included usage allowance. Ask your church appears in the member app only while
the paid add-on is usable and a billing administrator has enabled member
access. A billing, church-allowance, or daily fair-use message appears when
another reply is unavailable. Existing published sermon content remains
available to members even when AI generation is unavailable.

Members with an active or lapsed sponsorship can ask the assistant to
translate, lightly polish, or do both for a sponsor letter. The assistant sees
only the draft and language request—not the beneficiary's private identity,
guardian details, or safeguarding record. It returns an unsaved draft. The
member reviews and edits it, then submits it separately through the ordinary
encrypted moderation workflow.


# Analytics
Source: https://docs.thefaithapp.com/product/analytics

Review engagement, content activity, demographics, cohorts, notifications, app versions, and alert-driven analytics workflows in TheFaithApp.

# Analytics

This guide covers the analytics workspace used to understand engagement, audience trends, app adoption, and alert-based monitoring in TheFaithApp.

These tools include:

* Analytics dashboard
* Church Health
* Engagement analytics
* Content analytics
* Demographics analytics
* Cohort analysis
* Notification analytics
* App version analytics
* Custom metrics
* Analytics alerts

## Before You Start

* Sign in to your admin account.
* Open `Analytics` from the six-product sidebar, then choose the analytics page you need.
* Use the date range and platform filters when you want to narrow the results.
* Some analytics areas may show limited or empty data until your app has enough tracked usage.
* Church Health requires Analytics access. The identifiable inactive-member review also requires Members access; giving and care aggregates keep their own Giving and Pastoral Care permissions.

## Church Health

Use Church Health when your team wants to understand real participation,
follow-up, capacity, and broad pastoral needs without opening private member
patterns.

### What You Can Do

* Compare service, Event, Community Group, Volunteer, and kids-family check-ins
* Review first-time guest, visitor conversion, follow-up, new-member retention, and assimilation trends
* Compare participation by campus or ministry
* Review group participation, Volunteer coverage, care response, and matured attendance cohorts
* See near-full groups, Events, kids rooms, and uncovered Volunteer plans
* Review settled-gift participation by household stage when you have Giving access
* See consented prayer themes and optional wellbeing pulses only as protected church-wide aggregates
* Open a bounded inactive-member review when you also have Members access

### Steps

1. Open `Analytics`.
2. Click `Church Health`.
3. Start with the date range at the top.
4. Optionally choose a campus or ministry. Review the Data Confidence notes to see which sources can be filtered safely.
5. Review the counts beside every rate before drawing a conclusion.
6. Treat the inactive-member list as a prompt for a kind conversation, not as a score or an automatic follow-up list.

### Privacy Notes

* Prayer and wellbeing insight stays church-wide so filters cannot narrow a sensitive group down to an individual.
* Sensitive groups and household stages are hidden until at least five people or households are represented.
* Prayer text, pulse notes, care notes, child records, and private formation writing never appear in Church Health.
* Staff cannot open a member's My Quiet Season or reconnect signal. An Analytics user without Members access sees only the inactive count, not names.
* Giving uses settled gifts only and shows no amounts or donor identities. Care response shows assignment time only and no case details.

## My Church Rhythms for Members

Members can open `Connect`, then `My Church Rhythms`, to control the insight
they want for themselves.

They can:

* Turn on My Quiet Season for a private comparison of their own recent church rhythms
* Ask for a gentle reconnect nudge that goes to them, never to staff
* Follow that nudge into Groups, Prayer, Pastoral Care, or Events
* Share or withdraw one optional wellbeing pulse each day
* Choose “I'm not okay” and separately ask the care team to contact them
* Decide separately for each prayer request whether its anonymous theme may be counted
* Decide whether an answered testimony may return to the people who recorded that they prayed, after a seven-day reflection window

Withdrawing a wellbeing pulse removes its private note from the pulse record. A
care request the member deliberately created remains in the protected Pastoral
Care workflow so it is not silently cancelled.

## Analytics Dashboard

Use the main dashboard when you want one place to review sessions, users, engagement trends, and content performance.

![Analytics dashboard overview](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/analytics/dashboard-overview.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=265669ef49c934b9f6afb66eb564fdf7)

### What You Can Do

* Review session and user totals
* Check content views and media plays
* Compare current activity to the previous period
* Review engagement charts
* See platform distribution

### Steps

1. Open `Analytics`.
2. Stay on `Dashboard`.
3. Review the top cards first.
4. Use the date range and platform filters when you need a narrower view.
5. Click `Refresh` if you want to reload the latest totals.

### Notes

* The dashboard is the best first stop for day-to-day performance review.
* `Overview`, `Engagement`, and `Content` are tabs inside the main analytics dashboard, not separate left-nav pages.

## Engagement Analytics

Use the `Engagement` tab when you want to focus on sessions, new users, session duration, bounce rate, and device activity.

![Analytics dashboard engagement tab](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/analytics/dashboard-engagement.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=f75288a64003d9b6b9541e5ef0e734e0)

### What You Can Do

* Review total sessions
* Review new users
* Check average session duration
* Monitor bounce rate
* Compare activity by device

### Steps

1. Open `Analytics`.
2. Click the `Engagement` tab.
3. Review the top engagement cards.
4. Use the chart and device panel to understand how people are using the app.

### Notes

* This view is useful when you want to understand usage quality, not just raw traffic.

## Content Analytics

Use the `Content` tab when you want to review how sermons, media, and other content are performing.

![Analytics dashboard content tab](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/analytics/dashboard-content.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=7cf94aee4b2d4db078ac2eac6f828750)

### What You Can Do

* Review total content views
* Review media plays
* See how many content types are active
* Review top-performing content
* Check whether content activity is available for the selected date range

### Steps

1. Open `Analytics`.
2. Click the `Content` tab.
3. Review the top content cards.
4. Use the content breakdown and top-performing content panels to understand what people are consuming.

### Notes

* Empty content panels usually mean the selected period has little or no tracked content activity yet.

## Demographics Analytics

Use demographics analytics when you want to understand the makeup of your audience and how complete your user profile data is.

![Demographics analytics](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/analytics/demographics.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=afe0ce6d64826ddb1f0ff45ebb30f101)

### What You Can Do

* Review total users and sessions
* Check age, gender, and location data coverage
* Review age group distribution
* Review gender distribution
* Review top countries, regions, and cities

### Steps

1. Open `Analytics`.
2. Click `Demographics`.
3. Review the summary cards at the top.
4. Scroll down to the age, gender, and location sections.
5. Use the date range or platform filters if you want a narrower audience view.

### Notes

* Coverage percentages show how much demographic data is actually available in the current user base.
* Empty demographic sections usually mean those user profile fields have not been collected consistently yet.

## Cohort Analysis

Use cohorts when you want to understand retention, churn, and how groups of users behave over time.

![Cohort analysis](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/analytics/cohorts.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=e9db5805fc8c551c9741ea8363aaec81)

### What You Can Do

* Review total cohorts and total users
* Check average retention
* Review churn rate
* Compare active and churned users
* Inspect the cohort retention matrix
* Review churn by cohort period

### Steps

1. Open `Analytics`.
2. Click `Cohorts`.
3. Choose the period and number of months you want to analyze.
4. Review the overview cards first.
5. Use the retention matrix and churn table to study longer-term user behavior.

### Notes

* Cohorts are especially useful when your team wants to understand how well new users stay engaged after joining.

## Notification Analytics

Use notification analytics when you want to measure delivery and engagement for push notifications.

![Notification analytics](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/analytics/notifications.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=30f96c071726d42adb29cfd58e569b3e)

### What You Can Do

* Review total notifications sent
* Review delivered, opened, and clicked totals
* Check delivery, open, and click rates
* Review daily notification activity
* Compare notification activity by platform
* Review top-performing notifications

### Steps

1. Open `Analytics`.
2. Click `Notifications`.
3. Review the delivery and engagement cards at the top.
4. Scroll to the chart, platform split, and top notification sections.
5. Use the filters if you want to isolate one platform or period.

### Notes

* This page is useful for judging both technical delivery and audience response.
* A devotional notification is counted as sent when the push provider accepts it. This does not prove that a phone received it.
* Devotional delivery, open, and click totals reflect app callbacks. Missing callbacks leave those outcomes unconfirmed; a zero does not prove that no notification arrived.
* Each devotional topic send counts as one church-day occurrence. A delivered or opened occurrence means at least one app reported that event, not that every member received or read it. These are occurrence rates, not recipient rates.
* Devotional topic occurrences remain in the all-platform view because a topic may reach both iOS and Android. An individual callback cannot establish the platform of the whole audience.
* Foreground receipt reporting and notification taps depend on the installed app and its ability to contact the API. Background receipt is not comprehensively measured. Older apps may omit tap reports.
* Tracking begins with the updated notification service; earlier devotional sends are not reconstructed. No notification metric proves a completed ministry outcome.

## App Version Analytics

Use app version analytics when you want to track adoption of newer app releases and spot version-based performance differences.

![App version analytics](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/analytics/app-versions.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=174bd03d6fee36881bc95567bb39ded1)

### What You Can Do

* Review the latest app version in use
* Check the adoption rate for the latest release
* Compare users across app versions
* Review adoption trends over time
* Compare version performance
* Review latest-version recommendations

### Steps

1. Open `Analytics`.
2. Click `App Versions`.
3. Review the top adoption cards.
4. Use the version distribution and adoption trend sections to see how upgrades are spreading.
5. Review the performance comparison table for version-specific differences.

### Notes

* This view is especially helpful when you are encouraging users to upgrade to a newer app release.

## Alerts And Metrics

Use the reports area when you want to manage backend-driven custom metrics and analytics alerts.

![Reports custom metrics tab](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/analytics/reports-metrics.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=5e15aceed8eae9b45d1ecf0c51cb086d)

### What You Can Do

* Create custom metrics
* Review whether custom metrics are active
* Create analytics alerts
* Review alert totals, active alerts, and alerts triggered today

### Steps

1. Open `Analytics`.
2. Click `Reports`.
3. Stay on `Custom Metrics` when you want to manage saved metric definitions.
4. Open `Alerts` when you want to manage threshold-based alerts.
5. Click `Refresh` when you want to reload the latest configuration state.

### Notes

* This page currently focuses on custom metrics and alerts.
* The reports workspace is useful for teams that want more tailored monitoring than the default dashboard cards provide.

## Custom Metrics

Use custom metrics when your team wants to define a KPI that is more specific to your ministry or organization.

![Create custom metric drawer](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/analytics/custom-metric-drawer.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=a1c04d4a4ed4bf82694d3a510d54fd17)

### What You Can Do

* Name a custom metric
* Add a description
* Choose the metric type
* Choose the data source
* Choose the chart type
* Turn the metric on or off

### Steps

1. Open `Analytics`.
2. Click `Reports`.
3. Stay on `Custom Metrics`.
4. Click `Create Metric`.
5. Complete the metric details and save it.

### Notes

* Custom metrics are useful when standard dashboard totals do not answer a recurring business question.

## Analytics Alerts

Use alerts when you want TheFaithApp to flag important changes in your analytics thresholds.

![Reports alerts tab](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/analytics/reports-alerts.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=47c05e8a5d193d58d052ddaa1a67c67e)

### What You Can Do

* Review total and active alerts
* See how many alerts triggered today
* Create a new alert
* Activate or deactivate alerts after they exist
* Test alerts after setup

### Steps

1. Open `Analytics`.
2. Click `Reports`.
3. Open the `Alerts` tab.
4. Review the alert summary cards.
5. Click `Create Alert` when you want to add a new threshold rule.

### Notes

* Alerts are best for ongoing monitoring rather than one-time reporting.

## Creating An Alert

Use the alert drawer when you want to define the metric, threshold, and recipient list for analytics monitoring.

![Create analytics alert drawer](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/analytics/analytics-alert-drawer.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=64b5284328993b750b8d8975e7ac7188)

### What You Can Do

* Name the alert
* Add a short description
* Choose the metric to monitor
* Choose the condition
* Set the threshold value
* Set the period
* Add recipient email addresses

### Steps

1. Open `Analytics`.
2. Click `Reports`.
3. Open the `Alerts` tab.
4. Click `Create Alert`.
5. Fill in the metric, condition, threshold, and recipients.
6. Save the alert.

### Notes

* Recipient emails determine who receives the alert notification.

## Current Product Notes

* `Engagement` and `Content` analytics are part of the main dashboard tabs rather than separate left-nav pages.
* Church Health uses operational participation records rather than app opens. Its Data Confidence section explains source freshness, joined-date coverage, definitions, and any filter limitations.
* The current analytics web workspace exposes custom metrics and alerts, but it does not currently expose a separate scheduled reports screen in the admin UI we reviewed.
* Analytics tracking endpoints support app and integration data collection, but they belong in the API reference rather than the non-technical product guide.


# Authentication
Source: https://docs.thefaithapp.com/product/authentication

Invitation-based account setup, sign in, password reset, email verification, and two-factor authentication for TheFaithApp admins.

# Authentication

This guide explains how admins access TheFaithApp and recover access when needed.

The auth experience includes:

* Sign in
* Invitation-based account setup
* Forgot password
* Reset password
* Email verification
* Two-factor authentication challenge

## Sign In

Admins sign in with their email address and password from the sign-in page.

### Steps

1. Open `/sign-in`.
2. Enter the admin email address.
3. Enter the password.
4. Click `Sign In`.

![Sign in screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/auth/sign-in.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=da3a18d30c061a9a2e09cb6069732a0e)

### Current Behavior

* A successful sign-in opens the dashboard home page.
* If two-factor authentication is enabled, the user is asked to complete a verification step before access is granted.
* If the account email has not yet been verified, the user is taken to the email verification screen.

### Notes

* The sign-in page includes a direct link to `Forgot password`.
* The sign-in page does not link to account creation. New church administrators
  reach account setup only through a private invitation.

## Account Setup

New church accounts are invitation-only. A church first submits an access
request, or a Super Admin sends a direct invitation after qualifying the team.
See [Client onboarding](/product/client-onboarding) for the complete review and
invitation process.

### Steps

1. Open the private link sent to the approved email address.
2. Complete **Personal Info**. The invited email address cannot be changed.
3. Review **Church Info**. A website is optional.
4. Add a church logo, or continue with the default logo. You can add your own
   later in **Settings → Church Profile**.
5. Select **Complete Registration** and wait for the result.

### Collected Information

* User name
* Email
* Password
* Password confirmation
* Church name
* Church location
* Church email
* Church website (optional)
* Church logo (optional)

### Result

* The app confirms that your account is ready and starts sign-in. When automatic
  sign-in completes, you continue to the dashboard.
* If automatic sign-in cannot finish, the sign-in page confirms that your
  account is ready. Enter your invited email if it is not already filled in and
  use the password you just chose; you do not need another invitation.
* The invitation cannot be reused after account creation.

While registration is processing, wait before trying again. If setup fails before
the account is created, your entered details stay available for a retry while
the page remains open.

Invitation links expire after seven days. If the page says its secure link
session is unavailable, reopen the original invitation from your email. For an
expired, revoked or already-used invitation, follow
[Invitation problems](/product/client-onboarding#invitation-problems).

## Forgot Password

Admins who cannot access their password can start recovery from `/forgot-password`.

### Steps

1. Open `/forgot-password`.
2. Enter the account email address.
3. Submit the form.

### Result

* The app sends a password reset email.
* A success notification confirms the email was sent.

![Forgot password screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/auth/forgot-password.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=e90d64ee7d63b29059127eda684c01ad)

### Caveat

* The current page copy mentions a verification code, but the implemented flow sends a password reset email.

## Reset Password

The reset password page opens from the link sent in the password reset email.

### Expected Flow

1. Open the reset link from the email.
2. Enter a new password.
3. Confirm the new password.
4. Submit the form.

### Result

* A valid reset completes the password update.
* The app redirects the user back to `/sign-in` after a short delay.

### Caveats

* If the reset link is incomplete or expired, the page asks the user to request a new password reset email.

## Email Verification

If an admin account is not verified after sign-in, the app takes the user to the email verification screen.

### Available Actions

* Resend verification email
* Confirm that verification has already been completed
* Sign out

### Behavior

* If verification is completed from the email link, the page can continue the login flow automatically.
* After verification, the app returns the user to the main signed-in experience.

## Two-Factor Authentication

The app supports a second verification step for accounts that have two-factor authentication enabled.

### Supported Challenge Methods

* Authenticator code
* Recovery code

### Behavior

* If the user leaves the flow before completing verification, they need to sign in again.
* On success, the user continues into the dashboard.


# Children, Youth and Family Safety
Source: https://docs.thefaithapp.com/product/children-youth-family-safety

Prepare family records, safe rooms and sessions, secure child check-in, verified pickup, youth permissions, and emergency reunification.

Children & Youth gives church teams one safeguarding-first workspace for child
and youth ministry. Authorized guardians can keep family safety details current
in the mobile app, while approved staff can plan sessions, run check-in, page a
guardian, and verify each pickup.

> [!WARNING]
>
> TheFaithApp records permissions, warnings, and handoffs; it does not certify
> legal compliance or replace your church's safeguarding policy, trained
> leaders, emergency plan, or required background checks.

## Start With the Right Workspace

| Need | Open |
| - | - |
| Review today's attendance, pages, incidents, and staffing warnings | `Children & Youth > Overview` |
| Run preregistration, arrival, labels, paging, pickup, or reunification | `Children & Youth > Check-in & Pickup` |
| Record child safety details and guardian or pickup authority | `Children & Youth > Families` |
| Create ministry sessions and assign leaders | `Children & Youth > Sessions & Classrooms` |
| Manage youth groups, safe channels, events, and permission forms | `Children & Youth > Youth Ministry` |
| Record a restricted incident | `Children & Youth > Safety & Incidents` |
| Configure rooms, capacity, ratios, and two-adult coverage | `Children & Youth > Settings` |

## Before You Start

1. Name the leader accountable for your safeguarding policy and emergency
   response.
2. Confirm that every child has a member record with an accurate birth date.
3. Give ordinary management, check-in, and sensitive safety access only to the
   people who need each responsibility.
4. Agree on how legal guardians, custody restrictions, authorized pickup
   people, ID checks, and manual exceptions will be verified.
5. Confirm required volunteer screening outside TheFaithApp before recording a
   leader as cleared.
6. Create a test room and session, then rehearse arrival, label printing,
   paging, verified pickup, an incident, and emergency reunification.

## Set Up Rooms and Safe Staffing

Open `Settings` and create each children, youth, or family room. Record its age
range, capacity, maximum children per volunteer, minimum volunteer count, and
whether two cleared adults must be present.

Open `Sessions & Classrooms` to create a dated session. Choose the room,
check-in window, lesson title, and optional lesson-plan link. Assign leaders and
record their role, adult status, clearance status, and whether they are present.

The session shows warnings when its capacity, ratio, minimum staffing, or
two-cleared-adult rule is not met. A warning is a prompt for human action; it is
not an automatic safety approval.

## Create a Child Safety Profile

Open `Families`, then select `Create child safety profile`. Choose an existing
minor member and record only the information needed for safe ministry, such as:

* Preferred name and grade
* Allergies, medical or dietary notes, and accessibility needs
* Emergency contact details
* Custody or pickup restrictions
* Photo and media consent
* Emergency-care consent

Safety details and restrictions are protected separately from the ordinary
member directory.

### Add Guardian Authority

Add each guardian explicitly, including a guardian who is not in the child's
household. Grant only the responsibilities that person has: profile management,
check-in, pickup, waiver signing, or emergency contact.

Household membership alone does not grant legal authority. Revoking a guardian
stops future access while preserving the audit history.

### Add Authorized Pickup People

Record every person who may collect the child, their relationship, whether an
ID check is required, and an optional end date. Guardians can also add or revoke
pickup people from `My Family` when their relationship allows profile
management.

## Run Check-in and Pickup

A guardian can preregister an eligible child from `My Family` during the
configured check-in window. Check-in staff can also preregister the child after
choosing an authorized guardian.

1. Open `Check-in & Pickup` and choose the session.
2. Select `Arrive` only when the child is physically present. Preregistration
   alone does not count as attendance.
3. Select `Print labels` to print paired child and guardian pickup labels for
   active roster entries. The child label includes an allergy alert when one is
   recorded.
4. Use `Page guardian` when the guardian needs to return. The notification
   preview stays generic; the private message is visible only after opening the
   protected family page. Tapping the notification opens `My Family` whether
   the app is active, in the background, or starting cold.
5. At pickup, choose the authorized person and enter the guardian's six-digit
   code.
6. Confirm any required ID check and select `Verify & release`.

The pickup code expires when the child is released or the registration is
cancelled. A code mismatch never silently releases the child.

### Manual Pickup Override

Only staff with sensitive family-safety access can see the manual override.
Use it only after a supervisor verifies the exception. A reason is required,
and the release is recorded in the restricted audit history.

## Emergency Reunification

Use `Start emergency` on a live session to begin an accounted-for roster.
Authorized staff mark each checked-in child as accounted for and continue to
use verified pickup for releases. The emergency cannot be closed while a child
on the live roster remains unaccounted for.

Practice this workflow with your team before relying on it during an incident.
Keep your church's offline fallback roster and emergency procedure available.

## Incidents

Open `Safety & Incidents` to record a restricted incident for a child, with the
time, severity, short summary, action taken, and whether a guardian was
notified. Resolve the incident only after the church's required follow-up is
complete.

Keep the record minimal. Counseling, abuse disclosures, discipline casework,
and ongoing pastoral care belong in your church's formal safeguarding or
Pastoral Care process, not in casual leader notes.

## Youth Activities, Trips, and Waivers

Open `Youth Ministry` for direct links to the existing Events, Forms, and
family-safety session tools, plus invite-only youth-group management.

* Create the invite-only youth group, then assign youth, guardians, and
  approved adult leaders from member connections.
* Use the leader workspace for announcements, study guides, attendance, and
  brief operational notes.
* For a safeguarding concern, create the restricted Pastoral Care case first.
  Link only its case number from the bounded safeguarding-handoff note; keep
  the disclosure and care narrative out of group notes.
* Provision discussion or announcement channels. When minors are present,
  posting requires an active guardian or two approved adult leaders. Direct
  messages with a minor and disappearing messages are blocked.
* Create the activity or camp in Events for registration, capacity, payments,
  and reminders.
* Use the restricted `Youth activity permission` or `Camp and trip waiver`
  form template. Guardian signing authority is checked against the child's
  active relationship.
* Create a youth session when the activity also needs age, staffing,
  attendance, emergency-contact, and check-in safeguards.

These controls reinforce, but do not replace, the church's two-adult
communication and safeguarding policy.

## Send Parent and Guardian Announcements

Email and SMS campaign recipient selection includes reusable `All active
guardians`, `Guardians of children under 13`, and `Guardians of youth ages
13–17` audiences. Each audience refreshes from active explicit guardian
relationships and includes only guardians with a usable address or mobile
number for that channel. Revoked relationships and other churches' records are
excluded.

Operational parent pages remain protected, acknowledged safety messages with a
generic push preview; they are separate from campaigns.

## The Member Experience

Add the `My Family` system page to the church's mobile navigation in App
Customization when guardians should open it directly.

An authorized guardian can:

* See only children connected by an active explicit guardian relationship
* Review the safety details their relationship permits
* Update a child profile when granted profile-management access
* Add or revoke authorized pickup people
* See a Home family badge for active check-ins, unread pages, pending forms,
  and reminders
* Resolve child-specific consent, emergency-contact, profile-review, pickup,
  and form reminders
* Open pending permission forms and waivers under the correct child
* Preregister for an open session and show a large pickup pass
* Retain an active pickup pass temporarily in encrypted device storage when
  connectivity fails; it is removed after expiry, cancellation, or sign-out
* Read and acknowledge a ministry page opened from a generic push notification
* Continue to Bible plans, assigned permission forms, and church events

### Assigned Staff on Mobile

An adult volunteer sees mobile staff mode only for a current session where the
church has explicitly assigned them and recorded the required clearance. The
roster shows the minimum child safety details needed for the room, but never the
pickup code. Arrival and emergency accounting follow the assignment; paging,
verified pickup, and emergency start/end remain restricted to session leads.

Pickup codes, medical details, custody restrictions, and private page content
are not included in notification previews or ordinary directory views.

## Current Product Boundaries

* The clearance field records the status your church has already verified; it
  does not run a background check.
* External background-check providers, native printer verification, physical
  Android-device checks, iOS validation, signing, and store-track validation
  remain rollout gates rather than deferred product features.
* Android emulator QA verifies generic parent-page push display and My Family
  routing in foreground, background, and cold-start states. Populated emulator
  QA also covers offline/retry, staff roster privacy, emergency accounting,
  page acknowledgement, and verified release. Confirm native printer output,
  supported physical devices, iOS behavior, and store release gates before
  enabling the workflow for a live ministry session.


# Church Networks
Source: https://docs.thefaithapp.com/product/church-networks

Invite trusted churches, support church plants, coordinate shared ministry, and reuse resources without merging church data.

Church Networks gives trusted churches one place to coordinate while each
church keeps ownership of its members, care records, giving, and ministry
work. A church joins only after an invitation is accepted, and it can be
suspended or leave without erasing the historical record.

Staff work from **Church Network** in the dashboard. Members open **Church
Network** from Connect or from a navigation item their church publishes.

Network coordinators at the owner, parent, or regional church manage
invitations, church-plant support records, and filing requirements. Other
member churches can contribute their own submissions and take part in shared
work without changing network governance.

## Create or Join a Network

To create a network:

1. Open **Church Network**.
2. Add the network name, region, purpose, and a short governance summary.
3. Select **Create network**.
4. Open **Churches**, enter another church's public church UUID, choose its
   relationship, and send the invitation.

The invited church sees the invitation in its own dashboard and must accept
it before shared work becomes visible. The directory distinguishes parent,
plant, regional, and member churches.

Use suspension when access must stop temporarily. A suspended or departed
church loses future network access immediately, while past authorship and
audit history remain intact.

## Support a Church Plant

Open **Plants & support** to coordinate the relationship without turning the
network into the plant's database.

* Create a launch checklist and move each item from not started to in progress
  and complete.
* Submit a bounded parent-support report for a defined period.
* Record attendance and new-member vitals alongside optional, planter-shared
  rest and wellbeing signals.
* Create the agreed support taper, then add planned and actual ledger entries.

The taper ledger records a bilateral agreement; it does not transfer money.
Its totals and variance help both boards notice an unexpected reduction early.

> [!WARNING]
>
> Planter wellbeing is voluntary context for a caring conversation. Do not use
> it as a diagnosis, performance score, or automatic decision.

## Publish Shared Campaigns

Use **Campaigns** to publish a network event or prayer initiative. You can link
an existing public event from your church or publish a common prayer focus,
date range, summary, and call to action.

Members see active campaigns in the mobile Church Network hub. Event campaigns
open Events, while prayer campaigns open Prayer Community, so registrations
and prayer participation stay in their existing workflows.

## Coordinate Care and Benevolence Safely

A care-context transfer is a small, consented handoff for a member moving to a
sister church. Select the member and receiving church, record the consent time,
and share only the bounded context, preferences, and proposed next step. The
member can withdraw a pending transfer before the receiving church accepts it.

If a protected discipline/restoration case is linked to the member, an
assigned leader can optionally share only its current status. The member must
specifically consent to that status, and the receiving leader needs the
separate discipline permission before viewing or responding. The case title,
narrative, allegations, evidence, and restoration steps remain sealed at the
source church.

For benevolence, **Care & benevolence** can run a name-blind network check. It
does not disclose a person's identity or request notes. It only reports a safe
coordination reference when another church already has an active case for the
same normalized identity material. The workflow coordinates help; it does not
disburse funds.

## Share a Clearance Passport

An authorized leader can issue an expiring safe-to-serve passport only after
the member's local volunteer profile has the required current clearance and
the member has consented.

The available passport claims are checked against that local profile. A leader
cannot add a safeguarding, references, or code-of-conduct claim that the local
record does not currently support.

The member can copy the passport token from the mobile app. A receiving church
verifies that token to see the current claims, issuing church, and expiry. The
raw background report, provider response, report number, and private
eligibility notes are never shared.

> [!WARNING]
>
> A passport reports the issuing church's current reviewed status. It is not a
> new background check, legal certification, or substitute for local policy.

## Coordinate Pulpit Supply

Use **Pulpit supply** to:

1. Create a profile for a locally vetted preacher, including approved topics,
   a doctrinal summary, and a monthly limit.
2. Open a request for a dated service and record the expected handoff.
3. Let the sending church claim the request with an eligible profile.
4. Have the receiving church accept or decline the claim.

The monthly limit is checked against the service month before a claim is
created. Accepting a claim fills the request and closes other pending claims.

## Prepare Denominational Filings

Create a filing requirement with a due date, instructions, and required local
responses. Each member church reviews prefilled counts from its own current
records before submitting.

The network view rolls submissions up beneath the requirement while preserving
which church supplied each figure. Prefill is an aid, not an automatic filing;
the submitting church must review corrections and confirm the submission.

## Share and Adapt Ministry Resources

Use **Shared resources** for sermon packs, curricula, forms, campaigns,
devotionals, workflows, playbooks, volunteer training, event templates, and
sermon-series companions.

Every resource keeps its author church, version, license, usage guidance, and
review mark. A church can fork a published resource to adapt it; the new draft
retains its source and root lineage. Members can read published resources and
send field feedback from the mobile app.

A **Network blessed** mark records the network's review. It is not a claim that
the resource is universally correct for every church tradition or context.

## Permissions and Privacy

Church Network uses three levels of access:

* **View** for the directory, ordinary operations, campaigns, filings, and
  shared resources.
* **Manage** for invitations, plant work, campaigns, filings, pulpit supply,
  and resources.
* **Sensitive** for consented care, name-blind benevolence, clearance
  passports, planter wellbeing, and sensitive audit events.

Network membership is required in addition to the staff permission. Sensitive
details are encrypted, ordinary viewers see a restricted state, and important
membership, care, safety, resource, and workflow actions are recorded in the
network audit history.

## Payment Boundary

This release does not introduce an inter-church payment, escrow, marketplace
purchase, or paid resource license. No new payment-provider dashboard or
webhook setup is required.


# Church Operations
Source: https://docs.thefaithapp.com/product/church-operations

Manage members, imports, branches, gatherings, admin accounts, roles, and permissions in TheFaithApp.

# Church Operations

This guide covers the main church administration tools used to manage people, locations, schedules, and internal access.

These tools include:

* Members
* Member imports
* Import history and undo
* Branches
* Gatherings
* Admin accounts
* Roles and permissions

## Before You Start

* Sign in to your admin account.
* `Members`, `Branches`, `Gatherings`, and `Admins` are in the left sidebar.
* Some account-management actions depend on your own admin level.

## Members

Use Members to manage your church member directory and review engagement status.

![Members screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/church-operations/members.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=ce14b86f5e663c08dc8a5965f72a90c2)

### What You Can Do

* Review total, active, inactive, and new member counts
* Search the directory
* Filter by gender and activity status
* Open a member profile to see more details
* Resend an invite to members who have not logged in yet

### Steps

1. Click `Members` in the left sidebar.
2. Use the search field to find a member by name or email.
3. Use the gender and status filters when needed.
4. Click the view icon to open the member details drawer.
5. Use the resend invite action for members who still need access.

### Notes

* Member status is based on recent login activity.
* The view drawer shows contact, personal, location, and account details.

## Member Imports

Use a CSV file to add member records from another system. The
[Member Data Hygiene and Migration guide](/product/member-data-hygiene#validate-before-importing)
explains preparation, validation, duplicate review, and privacy safeguards.

### What You Can Do

* Choose a source system or **Other CSV** and download a sample template.
* Upload a CSV file and review the suggested field mapping.
* Validate and preview the rows before adding any members.
* Commit only accepted rows after reviewing the result.

### CSV Requirements

* Use a CSV file no larger than 10 MB, with up to 10,000 data rows.
* Map a full name, or at least one first/last name column, and at least an email or phone.
* Map the source system's person ID when it is available.

### Steps

1. Open **Members** and select **Import members**.
2. Choose the source system and upload the CSV.
3. Review and correct the suggested field mapping.
4. Select **Validate and preview**. This step does not add member records.
5. Review accepted, duplicate, rejected, and empty rows. Download the review
   CSV to investigate excluded rows.
6. Commit only the accepted rows when the preview is correct.

### Result

Only accepted rows are added to the directory. Duplicate, rejected, and empty
rows remain excluded. Importing does not send member invitations; review the
records and invite people separately when they are ready for access.

## Import History And Undo

Use **Import history** to review a migration or undo the records it added.
See [Undo and correct an import](/product/member-data-hygiene#undo-and-correct-an-import)
for the full workflow.

### What You Can Do

* Review migration status and outcome counts.
* Download the review file.
* Undo a completed migration's added member records.

### Steps

1. Open **Members**, then **Import history**.
2. Review the migration status and outcome counts.
3. Use the available undo action for a completed migration when needed.
4. Correct the CSV and upload it again, then run a fresh preview before
   committing any corrected rows.

### Notes

* Undo removes only the members added by that migration.
* A fresh preview checks a corrected file against the current directory.
* Keep member import separate from Visitor Inbox and its follow-up tasks.

## Branches

Use Branches to manage church campuses or locations.

![Branches screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/church-operations/branches.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=8b29fc608a3b4e86820a43ddc0a9cc9e)

![Create branch drawer](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/church-operations/branches-create.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=d18e598c4dc43ac26f93c6e765109a14)

### What You Can Do

* Create a branch
* Search branches
* Edit branch details
* Delete a branch

### Branch Details

* Branch name
* Location
* Pastor
* Contact

### Steps

1. Click `Branches` in the left sidebar.
2. Click `Add Branch`.
3. Enter the branch details.
4. Save the branch.
5. Use the edit or delete actions from the list when updates are needed.

### Notes

* If no branches exist yet, the page shows an empty state with a direct `Add Branch` action.

## Gatherings

Use Gatherings to manage recurring church services and meetings.

![Gatherings screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/church-operations/gatherings.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=d57f20e6a833c2def2ead26c5c2f15f7)

### What You Can Do

* Create a new gathering
* Search gatherings
* Filter by type or day
* Edit or delete a gathering
* Turn gatherings on or off with the active toggle
* View the list of available gathering types

### Gathering Details

* Gathering type
* Gathering name
* Day of the week
* Start time
* End time
* Description
* Active status

### Steps

1. Click `Gatherings`.
2. Click `Add Gathering`.
3. Choose the gathering type.
4. Enter the name, day, and time range.
5. Add an optional description.
6. Save the gathering.
7. Use the active toggle when you want to temporarily hide or reopen a regular gathering.

## Roles And Permissions

Use Roles and Permissions to control what each internal team role can access.

![Role permissions drawer](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/church-operations/admin-role-permissions.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=98cdf4d3e00af9a6feb69a8d372f1287)

### What You Can Do

* Create a new role
* Edit an existing role
* Assign permissions by category
* Select all permissions in one category
* Select all or clear all permissions across the whole role

### Permission Areas

* Content management
* Events and activities
* Communication
* Community
* Chat
* Media and finance
* Marketing
* Administration

### Steps

1. Click `Admins` in the left sidebar.
2. In `Roles & Permissions`, click `Create role`.
3. Enter the role name.
4. Select the permissions the role should have.
5. Save the role.

### Notes

* Roles are used when assigning or updating admin accounts.
* Existing roles can be opened again to adjust permissions later.

## Admin Accounts

Use Admins to manage internal staff and assign them to the right role.

![Admins screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/church-operations/admins.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=778f1b31c4f5f47119c8a9daa0142af2)

### What You Can Do

* Add a new admin account
* Search admin accounts
* Filter by role or group
* Change an admin’s assigned role
* Edit account details
* Delete an admin account when allowed

### Steps

1. Click `Admins`.
2. Click `Add Admin`.
3. Enter the admin name, email address, role, and password.
4. Save the account.
5. Use the group dropdown in the table when you want to reassign a role quickly.
6. Use the edit action for account updates.

### Notes

* The roles section sits above the accounts table on the same page.
* Some group changes or delete actions may be limited to higher-level admins.


# Client onboarding
Source: https://docs.thefaithapp.com/product/client-onboarding

Review access requests and invite qualified churches into TheFaithApp with a private account setup link.

# Client onboarding

TheFaithApp uses a reviewed, invitation-only onboarding process for new church
accounts. Public visitors can review product screenshots and setup guidance,
or request access without immediately creating an account.

## Explore before requesting access

Open a [product page](https://thefaithapp.com/products/church-management) to
review screen examples and setup guidance without an account. Choose
**Enlarge screenshot** beside an image to inspect it in a larger view.

Choose **View original size** to inspect details and scroll around the image.
Use **Fit to screen** to see the whole screenshot again. **Open full image**
opens the image directly.

Choose **Close** or press **Escape** to return to the product page. Keyboard
focus returns to the link you opened. If the viewer is unavailable, the link
opens the original image.

Screenshots are examples, not an interactive dashboard. The demo dashboard
requires sign-in. Review the product guidance and
[plans](https://thefaithapp.com/pricing) before requesting access.

For a visual overview, watch the
[88-second account-setup walkthrough](https://www.youtube.com/watch?v=acgKr3b4mGA).
It uses fictional details and AI narration to show the access request, private
invitation, registration and dashboard setup guide. Requests are reviewed;
submitting one does not create an account or guarantee approval.

## Request access

A church begins from the **Request access** page on the TheFaithApp website. The
form asks for enough context to understand the church, its goals, approximate
size, current tools, and desired start date.

If the form shows a **Security check**, complete it before sending the request.
An expired check can refresh automatically. Use **Retry security check** if it
cannot finish; your entered details stay on the page. If the check remains
unavailable, you can still explore the public product details and return to
the request later.

Submitting the form does not create an account. The page confirms receipt while
the request enters the Super Admin review queue and the platform review inbox
receives an alert. The applicant receives a receipt email explaining that review
is pending. This is not approval and does not promise a response time. Repeating
the same recent request does not send another receipt. Approved applicants later
receive a separate private invitation.

## Review a request

Super Admins can open **Client Onboarding** to see new requests and invitations
already in progress.

1. Select **Review** beside a church.
2. Confirm the church and contact details.
3. Record internal discovery notes.
4. Move the request through **New**, **Contacted**, or **Qualified**.
5. Send an invitation when the church is ready to proceed, or decline the
   request when it is not a fit.

Internal notes are visible only to Super Admins. The review panel also records
when an invitation was last sent, when it was first opened, when it expires,
and how many times it has been sent.

Once an account is created, review actions cannot decline the request, revoke
its invitation, or send another account setup invitation. Refresh an older
review panel to see the current status. Optional attribution can still be
removed when consent is withdrawn.

## Send a private invitation

Selecting **Send invitation** emails a private account setup link to the
approved contact. A Super Admin can also use **Invite a client** to invite a
church directly after an offline conversation.

Each invitation:

* is tied to the approved email address;
* can be used only once;
* expires after seven days;
* can be resent with a fresh link; and
* can be revoked before account creation.

The recipient confirms their details, chooses a password, reviews the church
information, and optionally uploads the church logo. Churches without a logo
use the default TheFaithApp mark until they upload their own in **Settings →
Church Profile**. Opening the email-bound invitation
also verifies the approved address, so completing setup does not send another
verification, welcome, or new-registration email. The account becomes active
only after setup is completed successfully.

During invited account setup, **Next Step** moves to the next section and
**Previous** returns to the earlier section without clearing its values. For
keyboard users, focus moves to the new step. If a section needs a correction,
focus moves to its first invalid field before you can continue.

After account creation, the app starts sign-in so you can continue to the
dashboard. If sign-in cannot finish, the sign-in page confirms that your account
is ready. Enter your invited email if it is not already filled in and use the
password you just chose; you do not need another invitation.

While **Complete Registration** is processing, wait for the result before
trying again. If setup fails, your entered details stay available for a retry.

## Your first steps after signing in

The main church administrator sees **Put your first church workflow to work**
on the dashboard. The five steps continue beyond account setup:

1. Use **Members → Add New Member** for one person, or **Import Members** for a
   CSV. Save a record first, or choose **Send a welcome invitation now** when
   the person is ready to receive sign-in details.
2. Publish your first form with public access. A connection-card template is a
   useful starting point. Test the public link before sharing it.
3. Check your church name, email and location in **Settings → Church Profile**.
   Details supplied during signup already count toward this step.
4. Share the published form with someone who wants to connect. A completed
   public response counts toward progress; unfinished or spam responses do not.
5. Open **Forms → Responses**, choose a response, assign a staff member and set
   a due date, then select **Save follow-up**. If the follow-up is already done,
   save its status as **Completed** instead.

A logo is optional and never holds back essential setup progress. You can add
or change it later. Publishing a form alone does not finish the guide. Once a
public response arrives, the reminder prioritizes its next step in
**Forms → Responses**, then returns to any unfinished setup work.

You can work on these steps in any order. Progress reflects saved church data
when you return to the dashboard; opening a page does not complete a step.
Draft, closed, archived and member-only forms do not complete the public-form
step. The compact reminder links to your next unfinished task; expand **Setup
steps** to review the full checklist at any time, including after completion.
This guide is for the main administrator, not restricted
staff accounts.

When all five steps are complete, **Your first church workflow is in place**
keeps response review within reach. Recording a next step does not send a
message or complete the actual follow-up for you. Continue checking your
response inbox and the work your team has agreed to do.

An **Active** onboarding request means the account was created. It does not
mean that every setup step is finished or that the church is actively using
the product.

## Account creation and activation

The onboarding workspace labels completed registrations **Account created**.
In the review drawer, **Church activation** separately shows whether the church
has a member, a published public form, and a completed non-spam public response.
All three are required for **Activated**. These are current-state indicators,
not permanent historical events: removing records or closing a form can change
the result. No member details or response answers appear in this summary.

## Compare acquisition activity

Use **Acquisition activity** to choose a start date, end date and reporting time
zone, then select **Apply dates**. The default is the last 28 complete days in
East Africa time. Choose the same dates and time zone as the analytics report
you are comparing. Pacific time is available for comparisons with Google Search
Console. The report is independent of the request-list search and status filters.

The report covers public access requests. It excludes manual invitations and
records marked as QA/test. Each saved enquiry counts once; repeating an accepted
submission does not create another enquiry. Separate enquiries saved later are
separate records, rather than a count of unique churches.

* **Unique enquiries** uses the date the enquiry was received.
* **Accounts created** uses the date the private invitation was accepted and
  the account was created. Each church account counts once.
* **Activations recorded** uses the first recorded completion of all three
  activation milestones. Each church account counts once.

Accounts and activations can come from enquiries received before the selected
dates. These are activity counts, not a cohort conversion rate. A first recorded
activation date is retained even if a form is later closed or a record removed.
Recording starts with this reporting feature; earlier activation dates remain
unknown. Some bulk updates are observed on the next five-minute check.

Source and medium are shown separately, so **google / organic** and **google /
cpc** remain distinct. Recognized search referrals can supply a source and
medium only after analytics-cookie acceptance. Linking those labels to a request
also requires the applicant's separate opt-in on the access form. Search terms
and full referring addresses are not stored for this attribution.

**Unattributed / unknown** includes enquiries without both consent choices or
available source information. It does not mean direct traffic. Earlier requests
are not filled in retrospectively, and these labels do not prove that a channel
caused a signup. Browser analytics may omit unconsented or blocked events; its
accepted-submission count can also include retries that did not create a new
saved enquiry.

Open a request to review its optional campaign source, campaign and content
label. A content label can distinguish a tracked post or link when the applicant
has opted in. Earlier requests are not filled in retrospectively, and a saved
campaign label does not establish an organic-search session.

Optional measurement does not affect whether an access request succeeds. If your
browser cannot keep optional storage, labels on the current tagged link can still
be attached after both choices are accepted; earlier visits may be unavailable.
Use the confirmation on the request page to know that it was received. An access
request is still subject to review and is not a created church account.

Open **Free tool activity** to see the same dated activity for **Church SMS
templates** and the **Visitor follow-up planner**. It uses the last free tool
visited in the previous 90 days with analytics consent, and attaches it only
when the applicant separately opts in on the access form. A request can be
linked without copying a message, downloading a plan, or using the tool's
Request access button. **Other or unattributed** includes requests without a
consented tool visit. Earlier requests are not filled in retrospectively.

## Keep QA separate

Use **Mark as QA/test** in the review drawer to exclude a synthetic record from
acquisition reporting, including after its account has been created. This does
not revoke access or change the church's onboarding stage. **Remove QA exclusion**
reverses the classification. Use **Show QA records in the request list** to find
excluded records; this does not include them in acquisition reports.

When preparing a test invitation, select **This is a QA/test invitation**. The
current pipeline cards also exclude QA but cover all dates and include ordinary
manual invitations. Review suspected spam separately; a random-looking name
does not automatically classify a request as QA or decline it.

Optional source, medium, campaign, content, and free-tool labels are removed after 90 days. Do not
put names, email addresses, or other personal information in campaign labels.
If an applicant withdraws consent, find their request and use **Remove attribution
on consent withdrawal**. Their application and church account are preserved.

## Public exploration and demo access

The public request page keeps two exploration options beside the form:

* **Explore product details** opens public screenshots, setup guidance, and
  plan details.
* **Demo dashboard sign-in** opens the dedicated demo sign-in page. You need
  demo access to use the dashboard.

Begin with the public product details to understand the platform without an
account. Use the access request to share your team's rollout, migration, or
fit questions for review.

## Invitation problems

If the page says its secure link session is unavailable, reopen the original
invitation from your email. This starts a fresh setup session while the original
invitation is still valid; you do not need to submit another access request.
The temporary page address is not a replacement for the email invitation.

If an invitation has expired, was revoked, or was already used, the setup page
does not expose the church details.

If you already completed setup, sign in with the password you chose. Use
**Forgot password** on the sign-in page if you need to reset it.

For an unused invitation that has expired or been revoked, contact TheFaithApp
so a Super Admin can review the request and send a fresh invitation when
appropriate. If you are unsure whether setup was completed, contact TheFaithApp
for help.

Connection failures show **Try again** instead of incorrectly treating an
invitation as expired. Failed signup submissions retain entered details while
the page stays open. Passwords are not saved as a browser draft. The dashboard
also offers **Try again** if its data cannot be loaded.


# Content Management
Source: https://docs.thefaithapp.com/product/content-management

Organize categories, manage sermons, publish devotionals and bulletins, and configure streaming in TheFaithApp.

# Content Management

This guide covers the main tools used to organize and publish church content in TheFaithApp.

These tools include:

* Categories
* Media library
* Audio sermons
* Video sermons
* Sermon AI tools
* YouTube in app
* Devotionals
* Digital bulletins
* Streaming

## Before You Start

* Sign in to your admin account.
* `Categories`, `Sermons`, `Devotionals`, `Bulletins`, and `Streaming` are in the left sidebar.
* Some actions, such as editing or deleting content, depend on your admin permissions.

## Categories

Use Categories to group sermons and keep content organized.

![Categories screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/content-management/categories.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=184124c8b8d66dedff3b059ceeaa1857)

### What You Can Do

* Create a new category
* Add an optional category image
* Search existing categories
* Edit a category name or image
* Open a category to manage its media
* Delete a category you no longer need

### Steps

1. Click `Categories` in the left sidebar.
2. Click `Add new`.
3. Enter the category name.
4. Upload a category image if you want one.
5. Save the category.

### Tips

* Use clear category names so members can find sermons more easily in the app.
* Open a category when you want to manage the audio and video content assigned to it.

## Media Library By Category

Each category has its own media library where you can switch between audio and video items.

![Category media library](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/content-management/media-library-category.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=270651aa41366ad976916c176c0a3779)

### Steps

1. Open `Categories`.
2. Click the view icon on a category card.
3. Use the `Audios` and `Videos` tabs to switch content types.
4. Click `Add Media` to add a new item directly inside that category.

### What You Can Do Here

* Keep related audio and video sermons together
* Search within the category
* Preview audio or play video content
* Edit or delete media from the same screen

## Audio Sermons

Use Audio Sermons to publish sermon recordings and other audio messages.

![Audio sermons screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/content-management/audios.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=36304639f69bcfc8116174be54d0737f)

### What You Can Do

* Add a new audio sermon
* Upload an audio file or use an audio link
* Assign the sermon to a category
* Add a cover photo, title, description, and duration
* Preview audio from the list
* Edit or delete existing audio sermons

### Steps

1. Open `Sermons` in the left sidebar.
2. Select `Audios`.
3. Click `Add new`.
4. Choose the category.
5. Add the title, description, and duration.
6. Upload the audio file or add the audio link.
7. Upload a cover photo.
8. Save the sermon.

## Video Sermons

Use Video Sermons to manage uploaded and linked sermon videos.

![Video sermons screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/content-management/videos.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=1b7ba92be0804f2938c7c31734990578)

### What You Can Do

* Add a new video sermon
* Assign the video to a category
* Add a cover photo, title, description, and duration
* Preview videos from the list
* Edit or delete existing videos

### Supported Video Sources

* Uploaded MP4 files
* Direct MP4 links
* YouTube video IDs
* Vimeo video IDs
* Dailymotion video IDs
* M3U8 and MPD streaming links
* Facebook public video links

### Steps

1. Open `Sermons`.
2. Select `Videos`.
3. Click `Add new`.
4. Choose the category.
5. Enter the title, description, and duration.
6. Choose the video source type.
7. Add the file, link, or video ID.
8. Upload a cover photo.
9. Save the sermon.

## Sermon AI Tools

Sermon AI helps your team turn sermons into readable transcripts, member-friendly study tools, translations, shareable drafts, quote cards, and video clips.

![Sermon AI tools on audio sermons](https://mintcdn.com/thefaithltd/pALyJg2Bi-XIdjdl/images/product/content-management/sermon-ai-audios.png?fit=max\&auto=format\&n=pALyJg2Bi-XIdjdl\&q=85\&s=8c44cc8305fac2d535ea59b23a72fdef)

### What You Can Do

* Generate a synced transcript for an uploaded audio sermon.
* Review transcript lines and publish them when they are ready for members.
* Ask for conservative cleanup suggestions while reviewing a transcript, then
  choose which suggestions to apply before saving.
* Generate sermon chapters from a reviewed transcript.
* Generate sermon insights, including a summary, key points, scripture references, reflection questions, and discussion prompts.
* Translate a reviewed transcript into supported languages.
* Create content drafts for social media, newsletters, bulletins, small-group
  guides, short devotionals, and short sermon snippets.
* Design and download quote cards from sermon excerpts.
* Suggest and download short clips for uploaded video sermons.

### Availability

* Audio sermon AI tools are available for uploaded audio sermons.
* Video transcript, translation, caption, and clip tools are available for uploaded video sermons.
* Linked or external videos, such as YouTube, Vimeo, Facebook, livestream links, M3U8, and MPD sources, do not show the same AI tools because the app does not own the source file.
* Sermon AI generation is part of the Digital Ministry Assistant add-on. Each church can try one free transcript before activating the add-on.
* Published sermon content stays available to members; the add-on controls staff generation tools, not member access to content that has already been published.

### Generate And Publish A Transcript

Use transcripts first. Chapters, insights, translations, content drafts, quote cards, captions, and clips all work best after the sermon has a reviewed transcript.

![Transcript review drawer](https://mintcdn.com/thefaithltd/pALyJg2Bi-XIdjdl/images/product/content-management/sermon-ai-transcript-drawer.png?fit=max\&auto=format\&n=pALyJg2Bi-XIdjdl\&q=85\&s=c2dff1c2bbdb133d4bc5e7ff4399ff15)

1. Open `Sermons`.
2. Select `Audios` for an uploaded audio sermon, or `Videos` for an uploaded video sermon.
3. Click the transcript icon or transcript status for the sermon.
4. Click `Generate transcript`.
5. Wait for the status to move from queued or processing to ready for review.
6. Review the transcript lines and timestamps.
7. Edit any lines that need correction.
8. Click `Save changes`.
9. Click `Publish` when the transcript is ready for members.

Use **Suggest cleanup** when you want help finding likely transcription errors.
Each suggestion shows the current wording, a proposed replacement, a reason,
and confidence. Applying a suggestion only changes the open editor; review the
result and use **Save changes** yourself. Uncertain wording is highlighted for
human review instead of being guessed or replaced automatically.

### What Members See

After you publish a transcript:

* Audio sermons can show a synced transcript player.
* Members can read along while listening.
* Members can tap transcript lines to jump to that moment.
* Uploaded videos can show synced captions from the published transcript.
* Members only see published transcripts and published translations.

If a transcript is not published, members keep the normal audio or video experience without seeing an empty transcript area.

### Create Chapters

Chapters help members jump to major sections of a sermon.

1. Open an audio sermon with a reviewed transcript.
2. Click the chapters icon.
3. Click `Generate chapters`.
4. Review the chapter titles and start times.
5. Edit titles if needed.
6. Click `Save changes`.
7. Click `Publish` when the chapters are ready.

Published chapters appear in the member sermon experience. Draft chapters remain private to admins.

### Create Sermon Insights

Sermon insights give members and staff a quick way to revisit the message.

1. Open an audio sermon with a reviewed transcript.
2. Click the insights icon.
3. Click `Generate insights`.
4. Review the summary, key points, scripture references, reflection questions, and discussion prompts.
5. Edit the content if needed.
6. Click `Save changes`.
7. Click `Publish` when the insights are ready.

Published insights are visible to members. Draft insights remain private to admins.

### Translate A Transcript

Translations help multilingual churches make sermons more accessible.

1. Open an audio sermon or uploaded video sermon with a reviewed transcript.
2. Click the language icon.
3. Choose a language.
4. Click `Translate`.
5. Review the translated transcript lines.
6. Edit any wording that needs correction.
7. Click `Save changes`.
8. Click `Publish` when that language is ready.

Members only see published languages. If a language is still in review, it remains hidden from the member app.

### Create Content Drafts And Quote Cards

Content drafts help staff reuse sermon material without starting from a blank page.

1. Open an audio sermon with a reviewed transcript.
2. Click the repurpose icon.
3. Click `Generate content`.
4. Review the social post, short snippets, newsletter summary, bulletin
   announcement, small-group guide, and short devotional.
5. Edit the text if needed.
6. Click `Save changes`.
7. Copy the draft you want to use.

Quote cards are created from sermon excerpts:

1. Open an audio sermon with a reviewed transcript.
2. Click the quote card icon.
3. Choose a suggested quote or write your own.
4. Pick the style that fits your church brand.
5. Click `Download PNG` to save the card as an image.

Content drafts and quote cards are staff tools. They do not publish directly to members.

### Create Uploaded Video Clips

Uploaded video sermons can use transcripts to suggest short shareable clips.

![Sermon AI tools on video sermons](https://mintcdn.com/thefaithltd/pALyJg2Bi-XIdjdl/images/product/content-management/sermon-ai-videos.png?fit=max\&auto=format\&n=pALyJg2Bi-XIdjdl\&q=85\&s=cea4a5054fe0512b7aca4ad88fb8de28)

![Video clip drawer](https://mintcdn.com/thefaithltd/pALyJg2Bi-XIdjdl/images/product/content-management/sermon-ai-clips-drawer.png?fit=max\&auto=format\&n=pALyJg2Bi-XIdjdl\&q=85\&s=858677a41b0b0ca7cb1677956a7ac470)

1. Open `Sermons`.
2. Select `Videos`.
3. Find an uploaded video sermon.
4. Click the clips icon.
5. Click `Suggest clips`.
6. Review the suggested start and end times.
7. Edit the clip title if needed.
8. Click `Generate` for the clip you want.
9. Click `Download` when the clip is ready.
10. Select `Publish to members` when members should be able to open and share
    the clip. Use `Withdraw` to remove it from the member app.

Clips are never posted automatically. A rendered clip remains staff-only until
an admin explicitly publishes it.

### Tips

* Review AI-generated content before publishing it to members.
* Publish the transcript before expecting members to see synced transcript or caption features.
* Use clear chapter titles that describe the sermon section, not only the topic.
* Keep translated transcripts reviewed by someone familiar with the language when possible.
* Regenerating content replaces the current AI draft, so save or copy any edits you want to keep first.

## YouTube In App

Use the YouTube settings drawer to surface a YouTube channel or playlist inside the member app.

![YouTube settings drawer](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/content-management/videos-youtube-settings.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=5519069a47142e5e08894462c98572aa)

### Steps

1. Open `Sermons` and select `Videos`.
2. Click `YouTube settings`.
3. Add the YouTube channel URL if you want to show the whole channel.
4. Add a playlist if you want to show only selected videos.
5. Turn on `Show YouTube tab in app`.
6. Use `Open preview` if you want to check how it will appear.
7. Click `Save`.

### Result

* Members can see a YouTube tab in the sermons area of the app when this feature is enabled.

## Devotionals

Use Devotionals to publish daily or recurring written reflections for members.

![Devotionals screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/content-management/devotionals.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=f04821d0a629f2916343be0018f21cbd)

### What You Can Do

* Create a new devotional
* Add the devotional date, author, title, and Bible reading
* Write the devotional content
* Add confession, studies, tags, and a thumbnail image
* Set recurring devotionals
* Choose whether to send notifications
* Generate a public devotional link
* Edit or delete devotionals later

### Steps

1. Open `Devotionals`.
2. Click `Add new`.
3. Fill in the devotional details.
4. Upload the thumbnail image.
5. Choose whether the devotional is recurring.
6. Set the notification time if you want to notify members.
7. Save the devotional.

### Public Sharing

* Use `Public Link` on the main page when you want a shareable devotional page or embed code.

## Public Devotional Page

Use the public devotional page when you want members or visitors to browse devotionals outside the admin dashboard.

![Public devotionals page](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/content-management/public-devotionals.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=abbc1c5ef8c436803ef8106be55b43db)

### What Visitors Can Do

* Browse the published devotionals
* Search devotionals from the public page
* Open a devotional to read the full reflection

### Steps

1. Open `Devotionals`.
2. Click `Public Link`.
3. Open the public devotional link.
4. Review the devotional list and use search if needed.
5. Click a devotional card to open it.

### Notes

* The public devotional page is designed for sharing outside the admin dashboard.
* Visitors can browse devotionals directly from the public page.

## Public Devotional Detail Page

Use the devotional detail page when you want to share one specific devotional or let readers open the full message from the public list.

![Public devotional detail page](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/content-management/public-devotional-detail.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=312678d00a6fdd97a3afd1f81df2a98c)

### What Visitors Can Do

* Read the devotional title, date, and author
* Review the devotional image and written reflection
* Use the back link to return to the devotional list

### Steps

1. Open the public devotional page.
2. Click the devotional you want to read.
3. Review the devotional content on the detail page.
4. Use `Back to Devotionals` when you want to return to the list.

### Notes

* Each devotional opens on its own public page, which makes it easier to share a single reflection.
* The public detail page reflects the content saved on the devotional record.

## Digital Bulletins

Use Digital Bulletins to publish church bulletins as either rich content or PDFs.

![Digital bulletins screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/content-management/bulletins.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=848c4ee720b6579df7a50654702f5c5c)

### What You Can Do

* Create a bulletin from scratch
* Upload a PDF bulletin
* Search and filter bulletins by status and type
* View bulletin details
* Publish drafts
* Archive published bulletins
* Duplicate a past bulletin
* Resend bulletin notifications
* Edit or delete bulletins

### Steps

1. Open `Bulletins`.
2. Click `Create Bulletin`.
3. Choose whether the bulletin will be `Native` or `PDF`.
4. Enter the bulletin title.
5. Add the content or upload the PDF.
6. Save it as a draft or publish it.

### Bulletin Types

* `Native` bulletins let you build content sections directly in the app.
* `PDF` bulletins let you upload a finished bulletin file.

For a native bulletin, choose a purpose for each section so members can scan
the service more easily. Available purposes include order of service, sermon
notes, Scripture, songs, announcements, events, giving, Connect Card, prayer,
kids and youth, and a general section. Sections keep the order set by the
church and can include church-authored links.

Each native section can contain text, a link or an image. Save announcements
and photos in a draft, review the content, then publish when it is ready for
members.

## Streaming

Use Streaming to manage both radio and live broadcast settings.

### Radio Streaming

![Radio streaming settings](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/content-management/streaming-radio.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=53797a3a13adba8c9f0fd69843e9b012)

### Live Streaming

![Live streaming settings](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/content-management/streaming-live.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=5aeaab55eecb80af6170b76047103281)

### Program Lineup

![Program lineup screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/content-management/streaming-program-lineup.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=54ab5a31e48208674f6599d746b2fa10)

### What You Can Do

* Configure radio streaming details
* Add or replace the cover image
* Set the stream URL and status
* Configure live stream settings
* Choose the live source type
* Preview radio or live streams before saving
* Build a weekly program lineup with days and times
* Add an optional WebVTT caption file for a church-managed stream
* Connect the broadcast to an existing on-demand sermon after the service
* Automatically turn a finished YouTube Live recording into a sermon
* Accept signed recording-ready webhooks from other streaming providers
* Notify members once when the stream changes from inactive to active

### Supported Live Sources

* RTMP live stream URLs
* YouTube Live video IDs
* M3U8 URLs

### Basic Steps

1. Open `Streaming`.
2. Use `Radio Streaming` to update the audio stream title, image, URL, and status.
3. Switch to `Live Streaming` to configure the live broadcast source.
4. Open `Program Lineup` to add scheduled shows and their broadcast times.
5. Preview the stream if needed.
6. Save the settings.
7. To archive a YouTube Live broadcast automatically, choose its sermon
   category under **Automatic on-demand archive** and click **Enable YouTube
   archive**.

For YouTube Live, TheFaithApp checks the saved video ID every five minutes. It
waits until YouTube reports that the broadcast has ended and its recording is
processed, then creates one on-demand sermon with YouTube's title, description,
duration, and thumbnail. No YouTube password or webhook secret is needed.

For another streaming provider, enter the provider name, choose the sermon
category, and enable the signed webhook. Copy the one-time signing secret into
the provider dashboard. The provider must send a durable HTTPS recording URL
after processing completes.

The optional archive media ID remains a manual handoff to an existing sermon;
it does not create a recording.

For reading plans, sermon next actions, member notes, offline listening, and
Scripture memory, read [Sermons and Bible Formation](/product/sermons-and-bible-formation).


# Dashboard and Internal Tools
Source: https://docs.thefaithapp.com/product/dashboard-and-internal-tools

Use the admin dashboard, AI chat assistant, feature requests, support, notifications, and profile tools in TheFaithApp.

# Dashboard and Internal Tools

This guide covers the main admin tools used after sign-in.

These tools include:

* Dashboard
* AI Chat
* Feature Requests
* Support chat
* Push Notifications
* Profile

## Before You Start

* Sign in to your admin account.
* Open `Church Management` in the left sidebar to find `Dashboard`, `AI Chat`, and `Notifications`.
* `Profile` and `Feature Requests` are in the profile menu at the top right.
* Use the chat button at the bottom right to contact TheFaithApp support.
* Some tools only appear if your account has permission to use them.

## Dashboard

The dashboard is the first page after sign-in. It opens with the people side of church life: who is new, who needs a call today, who is being cared for, and how giving is going. Church setup and content statistics sit further down the page.

Main church administrators also see a compact **Put your first church workflow
to work** reminder.
It shows their saved progress and a direct link to the next unfinished task.
Expand **Setup steps** to review church identity, the first member, and a
published public form, the first completed public response, and a saved follow-up
owner and due date or Completed status. Completed steps remain available without taking over
the dashboard. See [Client onboarding](/product/client-onboarding).

### What You Can Do

* See this week's new visitors, today's follow-ups, open care cases, and this month's gifts at a glance
* Work through the visitor follow-ups due today
* Check what needs attention across the church
* Watch recent activity as it happens
* Compare giving week by week
* Download or copy the mobile app subscribe QR code
* Review church information, media, and bulletin summaries

### The Four Tiles

| Tile | What it shows | Where it opens |
| - | - | - |
| New visitors this week | Visitors who first made contact in the last seven days, and how many are planning a visit. | Visitor Inbox |
| Follow-ups due today | Open visitor follow-up steps and member follow-ups due today, and how many are overdue. | Visitor Inbox |
| Open care cases | Care requests that are not yet resolved, with the urgent and unassigned counts. | Pastoral Care |
| Gifts this month | Completed gifts since the first of the month, with the total and the number of first-time givers. | Giving |

### Today's Priorities

Start with **Today's priorities**, above the four tiles. Follow-ups and attention
alerts appear together here. When neither needs action, a single **You're all
caught up** message replaces the empty lists. If information cannot be loaded,
use **Try again**; an unavailable list is not treated as an empty one.

* **Follow-ups due today** lists each open follow-up with the person's name, the task, and who owns it. Overdue items say how long they have been overdue. Click **Open** to handle one: a visitor follow-up opens the inbox, a member follow-up opens the member's profile. **All visitors** opens the inbox.
* **Needs attention** is the same list the header bell shows: overdue follow-ups, care cases without an owner, urgent care, profile changes to review, and new form responses. See [Search and the Attention Bell](/product/search-and-attention).

Expand **Recent activity and giving trends** below the tiles to see:

* **Recent activity**, a feed of the latest connect cards, gifts, form responses, care requests, and group joins across the church.
* **Giving, last 12 weeks**, which charts completed gifts by week and shows the change against the week before.

### Church Setup and Content

Expand **Church setup and content** to find:

* the church information card and branch count,
* the mobile app subscribe QR code with **Download QR Code** and **Copy Link**,
* the latest changelog entries,
* video, audio, bulletin, and membership statistics, and
* the donations report link.

### Steps

1. Open `Church Management` in the left sidebar.
2. Click `Dashboard`.
3. Start with **Today's priorities** and open any follow-up or alert needing action.
4. Use the four tiles to open the related workspace, or expand **Recent activity and giving trends** for more context.
5. Expand **Church setup and content** for the QR code, media, and bulletin summaries.

### Notes

* The tiles and lists only include people, cases, and gifts from your own church.
* Care items appear only if your account has the pastoral care permission.
* If the mobile subscribe setup is incomplete, the QR section can show a warning instead of the QR code.

## AI Chat

AI Chat helps admins draft content and get guided help inside the admin workspace.

![AI Chat screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/dashboard-internal-tools/ai-chat.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=24c8dba26c379e9eee5d435297e80f7c)

### What You Can Do

* Start a new AI conversation
* Use suggested prompts to get started faster
* Type your own prompt
* Draft visitor follow-up and Volunteer encouragement messages
* Summarize care history when your Pastoral Care access allows it
* Suggest next steps and Community Groups from current church records
* Find duplicate-member candidates and Volunteer schedule gaps
* Draft Event descriptions, announcements, weekly summaries, and ministry reports
* Search past conversations
* Rename, archive, or delete saved conversations

### Steps

1. Open `Church Management`, then click `AI Chat`.
2. Choose a suggested prompt or type your own message.
3. Send the prompt.
4. Use `New chat` when you want to start over.
5. Open the action menu on a past conversation to rename, archive, or delete it.

### Notes

* Access depends on your admin role or AI Chat permission.
* Search results and care context keep the permissions of their source screens.
* Generated messages, assignments, merges, announcements, and Events are drafts;
  AI Chat never sends, schedules, merges, or publishes them automatically.
* Review factual claims and every message before using it. The assistant is not
  a pastoral counselor or a replacement for a leader's judgment.
* If AI access is unavailable, the page shows a billing or reply-limit message with a link to `Settings`.
* Read [AI Assistance](/product/ai-assistance) for member answers, source
  citations, review boundaries, and availability.

## Feature Requests

Use Feature Requests to send product ideas to the support team.

![Feature Requests screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/dashboard-internal-tools/feature-requests.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=870449b6d125a669b969c9a80a8a94ba)

### Steps

1. Click your profile avatar in the top-right corner.
2. Select `Feature Requests`.
3. Enter a short title.
4. Describe the feature idea and why it would help.
5. Click `Send Feature Request`.

### Result

* The request is sent to the support team.
* Replies go to the email address on your admin account.
* A success message confirms the request was sent.

### Notes

* The title must be at least 5 characters.
* The message must be at least 20 characters.

## Support Chat

Open the chat button at the bottom right of the dashboard to talk with
TheFaithApp’s support team.

* Send a message, read the team's reply, and return to previous conversations.
* Your signed-in name, email, and church name help the team understand your question.
* Chat stays hidden while a drawer or dialog is open so your form buttons remain clear.
  Close the form to return to chat.
* If chat is unavailable, email
  [support@thefaithapp.com](mailto:support@thefaithapp.com).

The chat button replaces the separate Support page and menu item.
**Feature Requests** remains a separate place to send product ideas.

Visitors can also choose **Chat with us** on the TheFaithApp website without
creating an account. Leave a message if the team is away; an immediate reply is
not guaranteed.

Include what you were trying to do and any error wording so the team can help.

## Push Notifications

Use Push Notifications to send updates to church members.

![Push Notifications screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/dashboard-internal-tools/notifications.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=1a03142520e06646a00f5dec8fb4b335)

### What You Can Do

* Create a new notification
* Search past notifications
* Edit an existing notification
* Resend an existing notification
* Delete a notification

### Steps

1. Click `Notifications` in the left sidebar.
2. Click `Create Notification`.
3. Enter the notification title.
4. Write the notification message.
5. Send the notification.

### Managing Existing Notifications

* Use the search field to filter the list.
* Use the edit icon to update a notification.
* Use `Resend` to send the same notification again.
* Use the delete icon to remove a notification.

### Notes

* Create and edit forms open in a right-side panel.
* Existing notifications appear as cards with quick actions.

## Profile

Use Profile to update your personal account details.

![Profile screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/dashboard-internal-tools/profile.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=573a9009ede669e52bbe2fc8c8bd4141)

### Steps

1. Click your profile avatar in the top-right corner.
2. Select `Profile`.
3. Update your name or email address.
4. Upload or remove the profile photo if needed.
5. Enter and confirm a new password if you want to change it.
6. Click `Save Changes`.

### Notes

* Leave the password fields blank if you do not want to change your password.
* Profile photos accept JPG or PNG uploads.
* The current account role is shown on the page.


# Discipleship overview
Source: https://docs.thefaithapp.com/product/discipleship

Start with one church-owned pathway, then add mentorship and spiritual practices when your ministry is ready.

# Discipleship

Discipleship is TheFaithApp's dedicated formation product. It helps a church
teach what it believes, walk with people over time, and offer spiritual
practices without turning a member's private life with God into an admin
dashboard.

Use it for membership classes, baptism preparation, new-believer foundations,
leadership development, mentoring, prayer rhythms, or a pathway created for
your own ministry context.

![The member Discipleship hub with an active pathway and formation practices](https://mintcdn.com/thefaithltd/udQi4Xvr2yciLpwd/images/product/discipleship/member-hub.png?fit=max\&auto=format\&n=udQi4Xvr2yciLpwd\&q=85\&s=c115446cb22d7769ee0a6bedde16ebe1)

> [!NOTE]
>
> Discipleship is a top-level product. It uses your existing church members,
> staff accounts, campuses, volunteer opportunities, and permissions, but it
> does not live inside the Church Management menu.

## What you can build

> **[Classes and pathways](/product/discipleship-pathways)**
>
> Build sections, lessons, media, reflection prompts, discussions, and
> optional or scored quizzes.

> **[Mentorship and formation](/product/discipleship-formation)**
>
> Coordinate mentor pairings while keeping personal goals and journals under
> the member's control.

> **[Prayer and spiritual practices](/product/discipleship-practices)**
>
> Offer a Rule of Life, Daily Office, Guided Examen, fasts, lament, the church
> calendar, rest guides, and a Promise Ledger.

> **[Privacy and current scope](/product/discipleship-privacy)**
>
> Understand what staff can see, what stays private, and which capabilities
> are intentionally partial.

## A useful way to think about the product

| Part | What the church prepares | What the member experiences |
| - | - | - |
| Pathways | Lessons, questions, enrollment rules, teachers, and completion settings | A clear class journey with progress and, when enabled, a certificate |
| Mentorship | Programs, meeting rhythm, mentor pairing, and a shared check-in prompt | A named mentor and a shared record of agreed next steps |
| Personal formation | Optional goal templates and invitations | Private goals, progress notes, and journal entries |
| Spiritual practices | Church-shaped liturgies, seasons, prompts, and guides | Prayer and reflection experiences designed for personal participation |
| Gifts and serving | A church-authored discernment instrument and skill links | Private results and relevant open serving opportunities |

The church provides structure and invitation. The member still owns the parts
of formation that should remain personal.

## Your first pathway in about 30 minutes

**1. Choose one real ministry need**

Start with a pathway your church already understands, such as baptism
preparation or membership foundations. Write down the outcome in one
sentence: **After this pathway, a learner should be able to...**

**2. Choose the people responsible**

Ask one Discipleship manager to own setup, one teacher to maintain the
material, and one reviewer to check the content and correct answers before
publishing. One person may hold more than one role in a small church.

**3. Create a pathway**

In the admin dashboard, open **Discipleship → Pathways → Create pathway**.
Begin from a church-editable template or a blank pathway. Every template is
only a starting point.

**4. Build one short section**

Add two or three lessons. Give each lesson a clear teaching point, a
Scripture reference, and one next action. Add a quiz only when a correct
understanding is genuinely required.

**5. Preview, publish, and enroll a test member**

Check the member experience before inviting a whole class. Complete the
first lesson as the test member, confirm progress, and then review that
progress from the learner dashboard.

## Before you invite learners

Use this checklist for the first launch:

* Every required lesson has useful content.
* Required quizzes have at least one question and a confirmed correct answer.
* The passing score and attempt limit are compassionate and appropriate.
* The enrollment rule matches the ministry: open, approval-based, or
  invite-only.
* Assigned teachers have the correct Discipleship permission.
* The completion message tells learners what happens next.
* Certificate wording and signatory are correct if certificates are enabled.
* A staff member has tested the published pathway in the member app.

> [!TIP]
>
> A reliable first launch is more valuable than a large curriculum. Publish
> one pathway, learn from a small group, and add mentorship or spiritual
> practices when the ministry is ready to support them well.

## Who does what?

| Person | Typical responsibility |
| - | - |
| Discipleship manager | Creates pathways, assigns teachers, manages learners, and oversees the whole product |
| Teacher | Edits assigned pathways, teaches learners, and manages progress where permitted |
| Reviewer | Reviews assigned pathway content before publication |
| Progress viewer | Reads learner progress without changing enrollment or content |
| Member | Enrolls, completes lessons, participates in practices, and controls private formation data |

Permissions determine what a staff member may do. Assignment determines which
pathways or mentorship relationships they can access. Give each person only the
access they need.

## Where to go next

* Follow [Classes, quizzes, and learners](/product/discipleship-pathways) to
  build your first complete pathway.
* Read [Mentorship and personal formation](/product/discipleship-formation)
  before creating pairings or goal templates.
* Use [Spiritual practices](/product/discipleship-practices) when your church is
  ready to add prayer and reflection rhythms.
* Review [Privacy, safety, and current scope](/product/discipleship-privacy)
  before training staff.


# Mentorship and personal formation
Source: https://docs.thefaithapp.com/product/discipleship-formation

Coordinate shared mentorship while protecting private goals, journals, gifts results, and Rule of Life commitments.

# Mentorship and personal formation

Discipleship supports two different kinds of formation records:

* **Shared ministry records** help a mentor and mentee remember what they
  agreed to discuss or do together.
* **Member-private records** help a person reflect, set goals, and discern
  without creating a staff surveillance tool.

Keep that distinction clear when you train staff and members.

## Create a mentorship program

Open **Discipleship → Mentorship → New program**. Customize:

* Program name and description.
* Draft, active, or archived status.
* Expected duration.
* Weekly, every-two-weeks, monthly, or flexible meeting rhythm.
* The shared check-in prompt.
* Whether the member may add shared check-ins.

Activate the program when it is ready. A teacher can edit a program they
created; a Discipleship manager can manage every program.

### Write a safe check-in prompt

A good prompt prepares both people for a shared record:

> What did we agree to practice or revisit before our next conversation?

Avoid prompts that invite confidential disclosures into a shared field. For
example, do not ask for a full pastoral counseling note or a private confession.

## Pair a mentor and member

Discipleship managers select **Pair mentor**, then choose:

1. An active mentorship program.
2. An eligible mentor.
3. A member.
4. A start date.

In the current release, eligible mentors are existing staff who already have
the Discipleship management or teaching permission. This keeps the initial
workflow inside the church's staff authorization boundary.

An assigned mentor sees their own pairings. Managers can see all pairings.
Authorized staff can pause, resume, or complete a pairing without deleting its
history.

> [!NOTE]
>
> Lay-volunteer mentors depend on a future vetting and safeguarding workflow.
> Do not grant unnecessary staff permissions simply to make a volunteer appear
> in the mentor list.

## Keep shared check-ins

Open a pairing and select **Add check-in**. Record a shared conversation
summary and optional next steps. Check-ins are append-only and encrypted when
stored.

Every check-in is visible to both the mentor and mentee. Treat the saved text
as a shared agreement, not a private staff note. Correct a mistake with a new
check-in rather than silently rewriting the history.

## Offer private goal starting points

Open **Discipleship → Formation Tools → New goal template**. A template can
suggest:

* A name and description.
* Prayer, Scripture, community, service, rest, generosity, or another
  formation area.
* A number of days.
* A private progress prompt.
* Draft, active, or archived availability.

An active template appears in the member app as an optional starting point.
Members may rename it, change its wording, or create a goal from scratch.

The admin dashboard shows the template—not who chose it, the member's goal
wording, progress, or private reflections.

## Private journal and class reflections

Members can open **Personal formation → Private journal** and create:

* A general reflection.
* A reflection linked to one of their own pathway enrollment cycles.

Entries are encrypted when stored. Only the member may read, edit, or
permanently delete them. Linking an entry to a class helps the member organize
their own history; it does not expose the journal to a teacher.

> [!NOTE]
>
> Class-linked reflections are available. Cohort-linked reflections are not
> shown until a dedicated Discipleship cohort workflow exists.

## Build a gifts and serving instrument

Open **Discipleship → Gifts & Serving → New instrument**. Start with the
church-editable example or write your own. Customize:

* Introduction and low/high response labels.
* Gift or temperament areas and descriptions.
* Reflection questions and the area each answer contributes to.
* Question weights.
* Serving skills connected to each area.
* The delay before an unused strong gift is gently resurfaced.

In **Volunteers → Opportunities**, connect active opportunities to their
serving skills. Published results can then recommend open opportunities with a
plain-language reason for the match.

### Publish without changing old results

Publishing creates an immutable instrument version. Later question or scoring
changes do not alter an earlier member result. That preserves the meaning of
what the member originally completed.

Answers and results are encrypted and private. Instrument authors do not get
an answer or result dashboard.

A member with an active staff mentorship pairing may deliberately share one
result with their assigned mentor. Only that mentor can open it, add an
affirmation, and see it while access remains shared. The member can revoke
access at any time.

## Build a seasonal Rule of Life

Open **Discipleship → Rule of Life → New season**. Customize:

* Church-season name, dates, and invitation.
* Opening covenant and closing reflection prompts.
* Practice titles, guidance, and example rhythms.
* Required and optional practices.
* Draft, active, or archived availability.

Every template keeps prayer, rest, work, and generosity represented, while
your church owns the language and may add other practices.

Members create a fresh private draft for each season, personalize its
practices, covenant the rule, revise it during the season, and close it with a
private reflection.

> [!WARNING]
>
> The dashboard contains templates only. A member's covenant, commitments, and
> closing reflection are encrypted and owner-only. Rule of Life intentionally
> has no streaks, scores, or staff progress dashboard.

## A simple staff training script

Use this explanation before launching personal formation:

> The church creates invitations and starting points. Your personal goals,
> journal, gifts result, and Rule of Life remain yours. A mentorship check-in
> is different: it is a shared record that both mentor and mentee can read.

## Privacy summary

| Record | Member | Assigned mentor | Other staff |
| - | - | - | - |
| Mentorship check-in | Reads shared history | Reads shared history | Managers only where authorized |
| Personal goal and updates | Full control | No access | No access |
| Private journal | Full control | No access | No access |
| Gifts result | Full control | Only when the member shares that result | No results dashboard |
| Rule of Life | Full control | No access | Templates only |

For the full boundary, read [Privacy, safety, and current scope](/product/discipleship-privacy).

## Common problems

> **A mentor is missing from the pairing list**
>
> The person must be an eligible staff user with the correct Discipleship
> permission. Do not widen access unless their ministry role requires it.

> **Staff cannot see a member's goal or journal**
>
> This is expected. Goal and journal content is member-private by design.

> **A serving opportunity is not recommended**
>
> Confirm the opportunity is active and available, then connect its serving
> skills to the gift areas in the published instrument.

> **An earlier gifts result uses old wording**
>
> This is expected. Each result stays tied to the instrument version the
> member completed.


# Classes, quizzes, and learners
Source: https://docs.thefaithapp.com/product/discipleship-pathways

Build, publish, and run a complete church-owned learning pathway from the admin dashboard.

# Classes, quizzes, and learners

A **pathway** is a course or formation journey made from ordered sections and
lessons. Your church owns every word, question, answer, enrollment rule, and
completion setting.

## Choose the enrollment style first

| Enrollment | Best for | What the member sees |
| - | - | - |
| Open | Foundations or resources anyone may begin | **Enroll** and immediate access |
| Approval-based | Classes that need a conversation or scheduled cohort | **Request access**, followed by a pending state |
| Invite-only | Leadership, sensitive, or staff-selected training | The pathway remains locked until a teacher enrolls the member |

Choose this early because it determines how learners enter the pathway. You
can change it before publishing.

## Create the pathway

1. Open **Discipleship → Pathways**.
2. Select **Create pathway**.
3. Choose **Blank pathway** or a church-editable template.
4. Give the pathway a clear title and short description.
5. Select **Continue to builder**.

![The Discipleship pathway builder with sections, lessons, content, and settings](https://mintcdn.com/thefaithltd/udQi4Xvr2yciLpwd/images/product/discipleship/builder.png?fit=max\&auto=format\&n=udQi4Xvr2yciLpwd\&q=85\&s=5f58e404079eefd3afb2300f1ebb47c4)

Templates include common starting points such as membership foundations,
baptism preparation, new-believer foundations, serving foundations, and
leadership foundations. Replace any wording that does not fit your church.

## Build sections and lessons

Use sections to group related lessons. A membership pathway might look like:

```text theme={null}
Section 1 — Our story and beliefs
  Lesson 1 — Welcome and church story
  Lesson 2 — What we believe

Section 2 — Belonging and participation
  Lesson 3 — Community and care
  Lesson 4 — Serving and next steps
```

Each lesson can include:

* A title, summary, and expected time.
* Teaching text and Scripture.
* Video or audio links.
* Downloadable files.
* Reflection and group-discussion prompts.
* Required acknowledgements.
* Questions or a quiz.

Mark a lesson **required** only when it must count toward pathway completion.
Keep lessons focused; a short lesson with one clear next action is usually
easier to complete than an entire class session on one screen.

## Add questions and quizzes

Open a lesson and select **Add questions or a quiz**. Supported question types
are:

* Single choice.
* Multiple choice.
* True or false.
* Short answer.

For each question, write the prompt, accepted or correct answer, point value,
and an optional explanation. Correct answers are never sent with the lesson
content shown to the member.

### Decide whether a quiz is required

Use an optional quiz for self-checking. Use a required quiz when the learner
must demonstrate a clear understanding before continuing. For a required
quiz, set:

* The passing percentage.
* The maximum number of attempts.
* A helpful explanation for incorrect answers where appropriate.

> [!TIP]
>
> Do not score experiences that need prayerful reflection rather than a correct
> answer. Use reflection or discussion prompts for those moments.

> [!WARNING]
>
> Test every correct answer before publishing. A learner who uses all allowed
> attempts needs help from the teacher; do not use a strict attempt limit
> without a support plan.

## Configure completion

Pathway settings include:

* Pathway type and expected number of weeks.
* Enrollment style.
* Whether a completed or removed learner may repeat the pathway.
* The waiting period before a member-initiated repeat.
* Completion message.
* Certificate eligibility, title, award wording, signatory, and accent color.

If repeat enrollment is enabled, a new cycle uses the currently published
version and preserves the earlier journey. Approval-based repeats return to
pending review; invite-only repeats still require a teacher. Authorized staff
can start a repeat cycle even when the member waiting period has not ended.

When certificates are enabled, completing every required lesson issues a PDF
with a public verification code. The certificate keeps a snapshot of the
published wording used for that learner.

## Assign teachers and reviewers

Open **Teachers** in the builder. A Discipleship manager can assign:

* **Teacher** — may customize and maintain the assigned pathway.
* **Reviewer** — may inspect the assigned pathway before publication.

The creator remains the pathway owner. A staff member must already have an
appropriate Discipleship permission before they can be assigned.

## Publish safely

Publishing creates a fixed version. Learners already enrolled remain on the
version they started; later edits do not change their lessons or answers
halfway through the class.

Before selecting **Publish**:

1. Preview every required lesson.
2. Confirm required quizzes contain questions.
3. Check correct answers, score, and attempt limits.
4. Confirm enrollment and repeat rules.
5. Review the completion message and certificate.
6. Save the draft, then publish.

To make later changes, edit the draft and publish a new version. Do not expect
existing learners to move to it automatically.

## Manage learners

![The Discipleship pathway workspace with a published populated class](https://mintcdn.com/thefaithltd/udQi4Xvr2yciLpwd/images/product/discipleship/pathways.png?fit=max\&auto=format\&n=udQi4Xvr2yciLpwd\&q=85\&s=91fd2010a69629b0cf8e5a718c2838a6)

Open **Learners** from a pathway card or the builder. Authorized staff can:

* Approve or deny pending requests.
* Add existing church members.
* Search and filter enrollments.
* Review lesson completion and overall progress.
* Pause, reactivate, or remove an enrollment.
* Start a repeat cycle.
* Download, verify, or revoke a certificate.

A progress viewer can read progress but cannot change access. Revoked
certificates remain in the audit trail and fail public verification.

## Review formation history

Open **Discipleship → Formation History** for a cross-pathway view. It shows
each enrollment cycle, the pathway and version used, progress, dates, status,
and any issued or revoked certificate.

History is intentionally cycle-based. A second journey through the same
pathway never erases the first one.

## What the member experiences

In the mobile app, a member can review the outline, enroll or request access,
continue the next lesson, answer quizzes, see scores and remaining attempts,
track progress, finish the pathway, and access an eligible certificate.

They can also open **Formation History** to revisit earlier cycles and begin a
repeat when the pathway rules allow it.

## Common problems

> **A member cannot see the pathway**
>
> Confirm the pathway is published, the member belongs to the same church,
> and its enrollment style allows discovery. Invite-only pathways require a
> staff enrollment.

> **A teacher cannot edit the pathway**
>
> Confirm both pieces of access: the teacher needs a Discipleship permission
> and an assignment to that pathway.

> **The lesson will not complete**
>
> Check whether another required lesson item is incomplete or a required
> quiz has not reached the passing score.

> **A recent edit is missing for a learner**
>
> The learner may be using an earlier published version. That protects an
> in-progress class from changing. New enrollments use the current version.


# Prayer and spiritual practices
Source: https://docs.thefaithapp.com/product/discipleship-practices

Create church-shaped prayer, reflection, fasting, lament, calendar, rest, and promise-review experiences.

# Prayer and spiritual practices

Spiritual practices give members a formation rhythm beyond a class. Your
church prepares the invitation, language, and structure; members decide how
and when to participate.

Start with one practice your church can pastor well. Test it with staff before
publishing it to members.

## Daily Office

Open **Discipleship → Daily Office → New plan**. Configure:

* Title, active dates, and IANA timezone.
* Up to eight fixed prayer hours and their gentle bell invitations.
* Introduction and full order of prayer.
* Headings, readings, Scripture, prayers, responses, and timed silence.
* Draft, active, or archived availability.

Members choose which hours ring on their own device. Active liturgies are saved
for offline use, and the local bell schedule refreshes when Daily Office opens.

![A populated Daily Office plan with member-selected local prayer bells](https://mintcdn.com/thefaithltd/udQi4Xvr2yciLpwd/images/product/discipleship/daily-office.png?fit=max\&auto=format\&n=udQi4Xvr2yciLpwd\&q=85\&s=72fd226da2c4efc209170c2218076337)

Live presence is anonymous and temporary. A member may see **You and 3 others
are praying now** while an office is open. Staff cannot see identities, bell
choices, individual presence, or attendance history.

## Guided Examen

Open **Discipleship → Guided Examen → New Examen**. Configure:

* Title and suggested evening time.
* Opening and closing words.
* Ordered reflection steps and guidance.
* Presence, gratitude, review, consolation, desolation, forgiveness, tomorrow,
  or custom step types.
* Optional or required written responses.
* Automatic deletion from one hour to 30 days.
* Draft, active, or archived availability.

Every Examen must include gratitude and desolation. The church owns the
remaining language and order.

> [!WARNING]
>
> The deletion clock starts when the member begins; completion does not extend
> it. Responses are encrypted and owner-only. The member may delete early, and
> the platform permanently deletes the full session at expiry. Staff cannot
> inspect responses, participant names, or completion activity.

## Congregational fasts

Open **Discipleship → Congregational Fasts → New fast**. Configure:

* A one-to-90-day window and church timezone.
* Invitation, safety guidance, and closing blessing.
* At least one shared standard and one body-safe substitution.
* Up to eight total participation practices.
* Daily Scripture, reflection, and prayer.
* Draft, published, or archived availability.

Every option is presented as full participation. Members choose privately and
are never asked to submit a health reason.

Selected practices and daily check-ins are encrypted and owner-only. Staff see
only a total participant count—not names, choices, or check-ins. Leaving the
fast permanently deletes that member's participation record.

> [!TIP]
>
> Write the safety guidance before writing the fast invitation. Include
> substitutions that are genuinely accessible and encourage members to follow
> appropriate medical advice.

## Lament and Wall of Tears

Open **Discipleship → Lament & Wall of Tears → New liturgy**. Configure:

* Invitation, opening, and closing words.
* Ordered psalm, naming, protest, petition, silence, or custom movements.
* Whether the optional Wall of Tears is available.
* Wall heading, introduction, and offering prompt.
* Permanent deletion from one to 365 days.
* Draft, active, or archived availability.

Every liturgy retains at least one psalm and one naming movement. It does not
force grief toward a quick conclusion.

Private writing inside the liturgy stays only in memory on the current mobile
screen and is never uploaded. The Wall of Tears uses a separate blank field;
private words are never copied into it.

A wall offering is encrypted and waits for moderation. If approved, it appears
without the author's name. Moderators see the author only when the member
explicitly permits pastoral follow-up. Approval never extends the deletion
date, and the member may permanently delete the offering sooner.

## Living Church Calendar

Open **Discipleship → Church Calendar → New church year**. The included dates
are an editable Western-calendar example. Review every date against your
church tradition before activation.

Configure:

* Church-year title, description, dates, and timezone.
* Member welcome.
* Two to twelve non-overlapping seasons.
* Each season's name, dates, color, tone, invitation, and Scripture.
* Up to eight prayer, Scripture, generosity, fasting, service, rest,
  reflection, or custom practices per season.
* Daily, weekly, once-per-season, or flexible rhythm.
* Draft, active, or archived availability.

Only one church year may be active at a time. The member companion uses the
church timezone to move from one season to the next.

The calendar stores no attendance, completion, streak, or spiritual score.

## Sabbath and Retreat

Open **Discipleship → Sabbath & Retreat → New rest guide**. Configure:

* Sabbath or retreat type.
* Members, clergy, or everyone as the intended audience.
* Default duration from 30 minutes to seven days.
* Opening and closing invitations.
* Scripture reference.
* One to eight suggested practices.
* Draft, active, or archived availability.

Members decide whether to start, may change the duration, and can end early.
Only the current rest window is retained; expired and ended windows are
removed. Staff receive no participation analytics.

> [!NOTE]
>
> Rest mode suppresses church-wide broadcasts and direct church notifications,
> including chat, care, prayer-room, Volunteer, campaign, bulletin, devotional,
> and directory alerts. It remains active while the app is closed, and a
> signed-in staff device follows clergy rest windows. Device and emergency
> system alerts remain under the operating system's control.

## Private Promise Ledger

Open **Discipleship → Promise Ledger → New invitation**. Configure:

* Title and explanation.
* A gentle private-review question.
* Review interval from one to 90 days.
* Whether to include active personal goals, committed Rule of Life promises,
  or both.
* Draft, active, or archived availability.

The ledger reads only explicit structured commitments. It never scans journals
or infers promises from free-form writing.

Members can add an encrypted review note, snooze an item, set it aside, or
restore it. A review does not mark the source complete and creates no streak or
score. When the original goal or Rule of Life promise is no longer current,
its review state is removed.

The dashboard shows the invitation only—not member promises, notes, due counts,
or activity.

## Launch checklist for any practice

* The language sounds like your church and has been pastorally reviewed.
* Dates and timezone are correct.
* Privacy expectations are explained before participation.
* Safety language exists where the practice affects the body or sensitive
  personal experience.
* A staff member completed the whole member flow on a phone.
* Draft, active, published, and archived states behave as expected.
* Your ministry knows how to respond if a member asks for help.

## Common problems

> **A member cannot see a practice**
>
> Confirm it is active or published, its date window includes today where
> required, and the church timezone is correct.

> **Staff cannot see participation details**
>
> This is intentional for private practices. Some workflows provide only an
> anonymous total; others provide no participation analytics at all.

> **Daily Office bells did not ring**
>
> Confirm the member selected the prayer hour, allowed notifications on the
> device, and reopened Daily Office after a plan or schedule change.

> **Rest mode did not mute a church notification**
>
> Confirm the current rest window is still active, the device is signed in to
> the expected member or staff account, and notification state has refreshed.
> Operating-system and non-church alerts are outside TheFaithApp's control.


# Privacy, safety, and current scope
Source: https://docs.thefaithapp.com/product/discipleship-privacy

Understand who can see Discipleship data, how publishing protects learners, and which capabilities are intentionally partial.

# Privacy, safety, and current scope

Discipleship is designed around a simple boundary:

> The church may provide structure, teaching, and support without turning the
> admin dashboard into a window onto a member's private spiritual life.

This page should be part of staff onboarding—not only a technical reference.

## What staff can see

Authorized staff can see information needed to run a shared ministry workflow:

* Pathway enrollment, required lesson progress, quiz outcome, and completion.
* Published-version history and certificates.
* Mentor pairings and check-ins that are explicitly shared with both people.
* A gifts result only when the member shares that specific result with their
  assigned mentor.
* Anonymous or aggregate participation where a practice explicitly provides
  it, such as a fast participant total.
* A Wall of Tears author's identity only when the author requested pastoral
  follow-up.

## What remains member-private

Staff cannot inspect:

* Personal goal wording, updates, or private progress reflections.
* General or class-linked private journal entries.
* Gifts instrument answers or unshared results.
* Rule of Life drafts, covenants, commitments, or closing reflections.
* Daily Office bell preferences, identities, or attendance history.
* Guided Examen responses or participation.
* Fast choices, health reasons, or daily check-ins.
* Private writing composed inside a lament liturgy.
* Church Calendar participation or completion.
* Rest participation history.
* Promise Ledger items, notes, due counts, or review activity.

## Visibility matrix

| Experience | Church configures | Staff may review | Member-private data |
| - | - | - | - |
| Pathway | Content, quizzes, enrollment, certificate | Enrollment and learning progress | Private journal reflection |
| Mentorship | Program and shared prompt | Shared check-ins within authorization | Separate goals and journal |
| Personal goals | Optional templates | Templates only | Goal, updates, reflections |
| Gifts and serving | Instrument and skill mapping | Deliberately shared result only | Answers and default result |
| Rule of Life | Seasonal template | Template only | Covenant and commitments |
| Daily Office | Plan, hours, liturgy | No identities or attendance | Bell choices and participation |
| Guided Examen | Template and deletion window | No responses or activity | Full session until deletion |
| Congregational fast | Campaign and daily guide | Aggregate participant count | Choice and check-ins |
| Lament | Liturgy and wall moderation | Moderated offering; identity only with consent | In-liturgy private writing |
| Church Calendar | Seasons and practices | No member activity | No activity record is created |
| Sabbath and Retreat | Guides | No participation analytics | Current private rest window |
| Promise Ledger | Invitation and interval | Invitation only | Items, notes, and reviews |

## Privacy-aware staff habits

* Explain whether a field is shared before a person writes in it.
* Do not ask members to copy private journal content into a shared check-in.
* Do not use quiz scores as a measure of spiritual maturity.
* Do not widen staff permissions to solve a convenience problem.
* Do not export, screenshot, or copy sensitive formation content into another
  system.
* Use the dedicated pastoral-care workflow for confidential care—not a
  mentorship check-in.
* Treat anonymous totals as ministry context, not evidence about individuals.

## Publishing and version safety

Publishing a pathway or gifts instrument creates an immutable version.
Learners and results remain attached to the version they began. Later edits
create a new version instead of silently changing past or in-progress data.

This protects:

* The questions and answers used in a quiz attempt.
* The curriculum a learner was asked to complete.
* The certificate wording issued at completion.
* The questions and scoring behind a gifts result.

## Deletion and retention behavior

| Data | What happens |
| - | - |
| Private journal | Member may permanently delete an entry |
| Guided Examen | Member may delete early; otherwise the complete session is permanently deleted at the configured expiry |
| Fast participation | Leaving permanently removes that participation record |
| Wall of Tears | Member may delete early; remaining offerings are permanently deleted on the fixed schedule |
| Rest window | Ended and expired windows are removed |
| Promise Ledger review | Removed when the original commitment is no longer current |
| Certificate | Revocation preserves the audit record but invalidates public verification and download |

## Current partial or dependent capabilities

These boundaries are visible in the product so staff do not promise behavior
that does not exist yet:

* **Sabbath and Retreat notification protection is partial.** Church-wide
  broadcast-topic notifications are muted, but direct chat, care, prayer-room,
  volunteer, and other token-targeted alerts are not.
* **Clergy-device rest enforcement is partial.** It depends on a signed-in
  staff mobile identity and unified notification preferences.
* **Lay-volunteer mentor eligibility is dependent.** It needs an appropriate
  vetting and safeguarding workflow.
* **Cohort-linked journals are dependent.** Class-linked private reflections
  work now; a dedicated Discipleship cohort workflow does not yet exist.

> [!NOTE]
>
> “Partial” means the documented working portion can be used now, but the full
> intended behavior depends on another feature. “Dependent” means the product
> does not present that capability as available yet.

## Public API availability

Discipleship currently runs through TheFaithApp's first-party admin dashboard
and member apps. It is not yet included in the supported public partner `v1`
API.

Do not build third-party integrations against admin or internal mobile routes.
They are private implementation surfaces and may change without partner API
versioning guarantees. Read [Discipleship API availability](/api-reference/discipleship)
for the public integration boundary.

## Staff launch checklist

* Staff understand the difference between shared mentorship and private
  formation.
* Permissions match real ministry responsibilities.
* Published content and correct answers have been reviewed.
* Members receive an honest privacy explanation.
* Staff know which data is intentionally unavailable to them.
* Partial capabilities are described accurately.
* A support and safeguarding path exists for members who need help.


# Engagement and Communication
Source: https://docs.thefaithapp.com/product/engagement-and-communication

Manage prayer requests, segmented church communications, SMS conversations, campaigns, direct messages, group chats, invitations, and member-facing saved items in TheFaithApp.

# Engagement and Communication

This guide covers the communication tools your team can use to receive prayer requests, send announcements, and stay connected inside TheFaithApp.

These tools include:

* Prayer requests
* Public prayer request forms
* Segmented communications and weekly briefs
* SMS conversations and text-to-join keywords
* Church campaign seasons
* Direct messages
* Group chats
* Group invitations
* Favorites and bookmarks

## Before You Start

* Sign in to your admin account.
* Open `Prayer Requests`, `Communications`, or `Chat` from the left sidebar depending on the task you want to complete.
* Keep public links ready before you share them outside the admin dashboard.
* Review new requests and conversations regularly so follow-up does not stall.

## Prayer Requests

Use the prayer requests workspace to review submitted requests, track follow-up status, and share a public prayer request form.

![Prayer requests screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/engagement-communication/prayer-requests.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=8e13b2496cc374888bb1042f29e1f444)

### What You Can Do

* Review prayer request totals
* See recent requests quickly
* Search requests
* Filter by status
* Filter by request audience
* Filter by urgency status
* Filter by date range
* Open an individual request
* Export the current list
* Generate a public prayer request link
* Update prayer request settings

### Steps

1. Open `Prayer Requests`.
2. Review the summary cards and the recent requests section at the top.
3. Use search, status, audience, or date filters to narrow the request list.
4. Click the view icon when you need the full request details.
5. Use `Export`, `Generate Public Link`, or `Settings` when needed.

### Notes

* The request list is the main place for ministry teams to review incoming needs.
* Status updates make it easier for several team members to stay aligned on follow-up.

## Reviewing a Prayer Request

Use the request drawer when you need the full message and want to update the follow-up status.

![Prayer request view drawer](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/engagement-communication/prayer-request-view.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=064e2c16cac02cf217a3afd29e172eb4)

### What You Can Do

* Read the full request
* Review requester details
* Confirm whether the request is for the Church Prayer Wall, a Community
  Group, church leaders, or the pastoral team
* See answered and withdrawn request state
* Update the request status
* Review a member's private request for urgent follow-up
* Assign an urgent response owner and track acknowledgement, work, and
  resolution
* Create a locked Prayer Room with an eligible verified prayer-team leader
* Create and update a bounded Pastoral Care handoff
* Review pastoral access history when the request uses the restricted
  pastoral-only audience

### Steps

1. Open `Prayer Requests`.
2. Click the view icon for the request you want to review.
3. Read the message and confirm the requester details.
4. Update the status based on your current follow-up stage.

For a request marked for urgent review:

1. Review the member's private reason and approve or decline the urgency
   request.
2. Assign a staff owner when follow-up is needed.
3. Record when the need is acknowledged, in progress, and resolved.
4. If live prayer is appropriate, choose an eligible verified prayer-team
   leader and create a private Prayer Room.
5. If broader care coordination is needed, create a Pastoral Care handoff with
   a reason, owner, and short coordination note.

### Notes

* This view is useful for pastors, prayer teams, and follow-up coordinators.
* Recent requests at the top of the main page can also be opened from there.
* A withdrawn request cannot be returned to a member Prayer Wall.
* Member prayer journals remain private and never appear in this workspace.
  Only a request the member deliberately shares from a journal enters the
  normal review list.
* Urgency is private and does not appear as a badge on the member Prayer Wall.
* Urgent notifications contain a safe general message rather than the prayer
  text, requester identity, contact details, or private reason.
* The Pastoral Care handoff records coordination metadata only. It does not
  copy prayer or contact details, and it is not a full confidential care case.
* Pastoral-only requests require both Prayer Requests and Private Pastoral
  Prayer Requests access. Their content is encrypted, excluded from general
  search and export, and never shared into Prayer Walls, prayer teams, Prayer
  Rooms, or AI tools.
* When the pastoral audience filter is selected, `Export metadata` downloads
  workflow fields only and records the export in the request's access history.

## Public Prayer Request Links

Use the public link tool when your church wants people to submit requests without entering the admin dashboard.

![Prayer request link modal](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/engagement-communication/prayer-request-link-modal.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=239de73fc92b5bd9b9799504a6520159)

### What You Can Do

* Copy the public prayer request link
* Copy embed code for another website
* Share one destination for members, visitors, or livestream viewers

### Steps

1. Open `Prayer Requests`.
2. Click `Generate Public Link`.
3. Copy the direct link or the embed code.
4. Share it where people already reach your church online.

### Notes

* Public requests still flow back into the main prayer request review list.
* Public-form requests default to church leaders only and do not automatically
  appear in a member Prayer Wall.
* The embed option is useful when you want the form placed inside a church website.

## Public Prayer Request Page

Use the public page to collect requests from members, visitors, or online viewers.

![Public prayer request page](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/engagement-communication/public-prayer-request.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=a0bba495563bd2f49a762aaeada587a0)

### What You Can Do

* Submit a prayer request outside the admin dashboard
* Collect contact details for follow-up
* Give people a simple support path from a website or shared link

### Steps

1. Generate or copy the public prayer request link from the admin dashboard.
2. Share the link anywhere people already connect with your church.
3. Open the page outside the dashboard.
4. Fill in the request details and submit the form.

### Notes

* Review this inbox regularly so public requests receive timely follow-up.

## Communications

Use the Communications workspace to prepare an announcement, choose who
should receive it, and review its delivery history.

### Send an Announcement

1. Open `Communications` and stay on `Compose & history`.
2. Choose `Announcement`, `Weekly church brief`, or `Campaign update`.
3. Add the title and message.
4. Choose an audience such as all members, a campus, Community Group,
   ministry, volunteer team, member stage, event attendees, parents, recent
   guests, or campaign participants.
5. Click `Preview audience` and confirm the member and guest counts.
6. Choose the available in-app, push, email, SMS, or WhatsApp channels.
7. Save a draft for review or select `Publish now`.

The audience is checked again when the message is published. Later membership
changes do not rewrite the delivery history.

### Build a Weekly Church Brief

1. Choose `Weekly church brief` as the message type.
2. Add an optional prayer focus or important announcement.
3. Select `Generate brief`.
4. Review the collected events, serving schedule, Community Group updates
   when the brief targets one group, sermon recap, giving and outreach
   updates, and volunteer needs.
5. Edit the title or message before publishing.

Only available church content is included. Staff can always review the draft
before anyone receives it.

### Send an Emergency Alert

Turn on `Emergency communication` only when normal quiet choices and message
limits must be bypassed. Add the required reason, confirm the selected audience,
and publish. Emergency mode does not expand the audience or create missing
contact permission.

### SMS Inbox and Text-to-Join

Open `SMS inbox` to read inbound messages and reply through the church's
connected SMS number. The same area lets staff create a keyword such as
`PRAY` or `JOIN`. A person who texts the keyword receives the church's
confirmation and can text `STOP` to unsubscribe or `START` to renew consent.

Choose a distinct join keyword. The app reserves `START`, `YES`, `UNSTOP`,
`STOP`, `UNSUBSCRIBE`, `CANCEL`, `END`, `QUIT`, `HELP`, and `INFO` for text-message
controls. These words cannot be created as join keywords, even while paused,
or activated on an older keyword. Your connected provider may reserve additional
words, so check its keyword settings before sharing instructions.

Older keywords are not changed automatically. Changing an older keyword's name
or confirmation reply does not replace its text word or pause it. Create a
distinct replacement before publishing new text-to-join instructions.

### Member Choices

Members can open Communication preferences from Notifications in the mobile
app. They can choose non-critical topics, delivery channels, quiet hours, and
daily or weekly message limits. Emergency alerts are not counted against those
limits.

Email, SMS, WhatsApp, and push require the church's corresponding provider to
be configured. In-app delivery remains available without an external provider.

## Church Campaigns

Use a church campaign for a focused season such as 21 days of prayer, missions
month, Serve Week, or an Easter invitation.

1. Open `Communications`, then `Church campaigns`.
2. Add the campaign title, summary, optional theme, and dates.
3. Link a devotional, event, giving fund, Outreach Campaign, Bible plan, form,
   or prayer focus.
4. Save the draft, review it, and publish it.

Published campaigns appear in the member app. Their resources open the
existing event, giving, prayer, devotional, Bible, or form areas, so the
campaign does not create duplicate registrations, gifts, or participation
records.

## Chat Workspace

Use chat to keep one-to-one and group conversations active across the admin dashboard and the mobile app.

![Group chat workspace](https://mintcdn.com/thefaithltd/aFSprC3bftpn0TVr/images/product/engagement-communication/chat-groups.png?fit=max\&auto=format\&n=aFSprC3bftpn0TVr\&q=85\&s=99bafd591c81799cbadb9c3416b24075)

### What You Can Do

* Switch between `Personal` and `Groups`
* Search conversations from the chat list
* Review the latest message and time for each room
* Read and reply to messages
* See unread activity when new messages arrive
* Open a room and continue the conversation
* Start a new chat from the admin dashboard when your role allows it

### Steps

1. Open `Chat`.
2. Use `Personal` or `Groups` to switch conversation types.
3. Select the conversation you want from the list.
4. Read the latest messages in the thread.
5. Type your reply, attach a supported file, or attach a sermon.
6. Send the message.

### Notes

* The shared chat workspace keeps direct messages and group threads in one place.
* Messages update in realtime between the admin dashboard and mobile app.
* Group chats work well for ministry teams, church-wide updates, internal coordination, and recurring planning.

## Direct Messages

Use direct messages when you need a one-to-one conversation with a member or another user.

![Personal chat screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/engagement-communication/chat-personal.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=0b1399daf20a3a41990c19e897a461d3)

### What You Can Do

* Open an existing direct message
* Continue a private conversation
* Reply inside the same thread

### Steps

1. Open `Chat`.
2. Stay on `Personal`.
3. Select the conversation you want to open.
4. Type your message and send it.

### Notes

* Direct messages are best for one-to-one follow-up, coordination, or support.
* Direct message notifications follow the recipient's chat notification preferences.

## Group Chat Messages

Use group chats when several members need to follow the same conversation.

![Rich group chat messages](https://mintcdn.com/thefaithltd/aFSprC3bftpn0TVr/images/product/engagement-communication/chat-room-rich-messages.png?fit=max\&auto=format\&n=aFSprC3bftpn0TVr\&q=85\&s=b07bf305bcdab77e96509a6c878d414f)

### What You Can Do

* Read messages grouped by date
* See read receipts such as `Seen by 1` or `Seen by 5`
* Reply to a specific message
* React with quick faith-community reactions
* Mention another member in a group
* Play sermon attachments from the message
* Listen to voice notes
* Delete messages when your role allows moderation

### Steps

1. Open `Chat`.
2. Click `Groups`.
3. Open the group you want.
4. Scroll up to review older messages.
5. Use `Reply` when you want your response linked to a message.
6. Use a reaction when a short response is enough.
7. Type `@` and choose a member when you need to mention someone.

### Notes

* New messages appear without refreshing the page.
* The unread divider marks where new activity begins when you return to a room.
* Mentioned members receive stronger chat attention based on notification settings.

## Attachments, Voice Notes, and Sermons

Use attachments when a conversation needs more than text.

![Mobile sermon attachment in chat](https://mintcdn.com/thefaithltd/aFSprC3bftpn0TVr/images/product/engagement-communication/chat-mobile-room.png?fit=max\&auto=format\&n=aFSprC3bftpn0TVr\&q=85\&s=31e6a22623538e33ae04679ec391d037)

### What You Can Do

* Send supported image attachments
* Send supported PDF attachments
* Preview images from the chat room
* Open PDFs from the chat room
* Attach audio or video sermons
* Play sermon attachments from the chat card
* Send and play voice notes on mobile

### Steps

1. Open the chat room.
2. Click or tap the attachment icon for an image or PDF.
3. Choose the file and wait for the upload to finish.
4. Use the sermon icon when you want to attach a sermon.
5. Search for the sermon and select it.
6. Send the message.

### Notes

* Chat file attachments currently support images and PDFs.
* Sermon attachments open in the mobile app player on mobile.
* On web, sermon attachments use browser playback controls.
* Upload progress appears before the message finishes sending.

## Group Info and Members

Use the group info drawer to review members and shared content from one place.

![Group info drawer](https://mintcdn.com/thefaithltd/aFSprC3bftpn0TVr/images/product/engagement-communication/chat-group-info.png?fit=max\&auto=format\&n=aFSprC3bftpn0TVr\&q=85\&s=2d27be4d4dbe99dd0cfd88191ffcad55)

### What You Can Do

* Review the group name
* Confirm whether the group is public or private
* See the current member count
* Review members
* Load more members in larger groups
* Review shared photos
* Review shared PDF files
* Review shared sermons
* Open shared files or sermons from the drawer
* Mute or moderate members when your role allows it

### Steps

1. Open `Chat`.
2. Click `Groups`.
3. Open the group conversation you want.
4. Click the group header.
5. Use `Members`, `Photos`, `Files`, or `Sermons` to review the shared group history.
6. Open a shared photo, PDF, or sermon when you need to preview it.

## Joining Public Groups

Use public groups when members should be able to read a room before joining the conversation.

### What You Can Do

* Open a public group from the chat list
* Read the existing conversation
* Review group details before joining
* Join the group when you want to participate

### Steps

1. Open the mobile app.
2. Go to `Chat`.
3. Open the public group you want to view.
4. Review the messages or group details.
5. Tap `Join` when you want to send messages in that room.

### Notes

* Members who have not joined can read the room, but they do not see the message input until they join.

## Chat Notification Preferences

Use notification preferences when a room is useful but temporarily too busy.

### What You Can Do

* Keep notifications on for important rooms
* Mute a room for a short period
* Mute a room for the day
* Turn off room notifications when needed
* See which mute option is currently selected

## Favorites and Bookmarks

Use favorites and bookmarks as member-side save-for-later tools inside the app experience.

### What You Can Do

* Save content for quick return later
* Help members keep track of meaningful sermons or devotional content
* Support follow-up when a member says they saved an item to revisit

### Notes

* Favorites and bookmarks are member-facing features rather than a separate admin workspace.
* The current web dashboard does not expose a standalone favorites or bookmarks management page.

## Current Product Notes

* The admin pages reviewed for this guide include prayer requests, communications, SMS conversations, church campaigns, direct messages, group chats, room details, and chat moderation actions.
* Chat rooms are created and managed from the admin experience.
* Favorites and bookmarks remain member-facing saved-item features.


# Events and Volunteers
Source: https://docs.thefaithapp.com/product/events-and-volunteers

Plan church events, configure registration, and manage volunteer ministries, opportunities, skills, and signups in TheFaithApp.

# Events and Volunteers

This guide covers the main tools used to manage events and volunteer coordination in TheFaithApp.

For team rosters, recurring schedules, availability, wellbeing, training, and
worship plans, continue to [Volunteers and Serving Teams](/product/volunteers-and-serving-teams).

These tools include:

* Events
* Event categories
* Event registration setup
* Attendee management and check-in
* Public event pages
* Volunteer ministries
* Volunteer categories
* Volunteer skills
* Volunteer opportunities
* Volunteer signups

## Before You Start

* Sign in to your admin account.
* `Events` and `Volunteers` are in the left sidebar.
* Some create, edit, or delete actions depend on your admin permissions.

## Event Categories

Use Event Categories to organize events by theme, audience, or purpose.

![Event categories screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/events-volunteers/event-categories.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=8839b35c732b3d61036fe21a3acd84e8)

### What You Can Do

* Create a new event category
* Add a description and color
* Mark a category as active or inactive
* Search categories
* Edit or delete existing categories

### Steps

1. Open `Events`.
2. Select `Event Categories`.
3. Click `Add new`.
4. Enter the category name, description, and color.
5. Set the category status if needed.
6. Save the category.

### Tips

* Use category names that make event filtering easier for your team.
* Keep inactive categories for older event types you do not want to remove yet.

## Events

Use Events to plan services, groups, classes, rehearsals, outreach programs, conferences, and other church activities.

![Events screen](https://mintcdn.com/thefaithltd/uLYp005rAsK2J5Ev/images/product/events-volunteers/events.png?fit=max\&auto=format\&n=uLYp005rAsK2J5Ev\&q=85\&s=2122de79e0eac41e14ef8ec0dc9680dc)

### What You Can Do

* Create a new event
* Add a cover image, date, time, and location
* Assign the event to a category
* Switch between a list and a calendar
* Search and filter events by category or publication status
* Open an event details drawer without leaving the calendar
* Review registrations or run check-in from the same event workspace
* Review the next occurrence of a recurring event
* Edit or delete existing events
* Repeat an event daily, weekly, every two weeks, monthly, or yearly
* Publish an invite-friendly public event page

### Event Details

* Event title
* Event description
* Date and time
* Cover image
* Category
* Location name and address
* Recurring or multi-day options
* Registration, reminder, and check-in settings

### Steps

1. Open `Events`.
2. Click `Create event`.
3. Enter the event title and description.
4. Add the date, time, and cover image.
5. Choose the event category.
6. Add the location details.
7. Turn on recurring scheduling when the gathering repeats.
8. Turn on `Public event` when people should be able to open and share its public page.
9. Save the event.

### Notes

* Event cards show the next occurrence, location, registration state, price, capacity, and recurring status.
* Past events remain visible with a visual status change, which helps with reference and cleanup.
* Each occurrence of a recurring event keeps its own registration and attendance list.

## Private Calendar Subscriptions

Use private calendar subscriptions when a trusted person or shared calendar
needs a read-only schedule that stays up to date automatically. An administrator
with Events access can create a named subscription for:

* Published public Events
* Published or completed services for one campus
* Published or completed services for one ministry
* All published or completed volunteer services

Drafts, registrations, member names, assignments, safeguarding information,
and internal notes are never included.

### Create and Subscribe

1. Open `Events` and find `Private calendar subscriptions`.
2. Select `Create subscription`.
3. Give the subscription a recognizable name, such as `Downtown display`.
4. Choose the calendar scope and, when requested, the campus or ministry.
5. Create the subscription, then select `Reveal and copy`.
6. Paste the copied URL into the calendar application:
   * **Apple Calendar on Mac:** choose `File` > `New Calendar Subscription`,
     paste the URL, and choose how often it should refresh.
   * **Google Calendar on a computer:** beside `Other calendars`, choose
     `Add other calendars` > `From URL`, paste the URL, and add the calendar.
   * **Outlook on the web:** open Calendar, choose `Add calendar` >
     `Subscribe from web`, paste the URL, and import it.

Provider help: [Apple Calendar](https://support.apple.com/guide/calendar/subscribe-to-calendars-icl1022/mac),
[Google Calendar](https://support.google.com/calendar/answer/37100), and
[Outlook](https://support.microsoft.com/en-us/outlook/import-or-subscribe-to-a-calendar-in-outlook-com-or-outlook-on-the-web).

> [!NOTE]
>
> Subscribe using the URL instead of uploading an `.ics` file. A subscription
> receives future schedule changes; a one-time file import does not.

### Protect a Private URL

Treat the URL like a password. Anyone who has it can read that calendar until
it is replaced or revoked. Use a separate named URL for each trusted person,
display, or external calendar so access can be removed without disrupting
other subscriptions.

* Select `Rotate URL` to replace a URL that may have been exposed. The previous
  URL stops working immediately, and the calendar must subscribe again with
  the new one.
* Select `Revoke` when the calendar should stop receiving updates. A revoked
  subscription can later create a new URL.
* Rename a subscription when its purpose changes. Renaming does not replace
  its URL.

Calendar providers decide how often they refresh subscriptions, so a schedule
change may not appear immediately.

## Connect Google Calendar or Outlook

Open **Events > Calendar subscriptions** and find **Connected calendars** to connect a church-owned Google or
Outlook account. Choose a calendar you can edit, then choose whether to include
published events, serving plans, or both. The connection stays within your
church and has its own sync history.

TheFaithApp keeps event times, locations, and cancellations up to date in the
selected calendar. Make schedule changes in TheFaithApp. Editing a copied event
in the calendar does not change the church schedule, and the next sync restores
the schedule details.

Members can open **Volunteer Hub > My schedule** in the mobile app to connect
their own calendar for registered events and serving assignments. Staff who
also have a member profile can use **Volunteers > Schedule & Teams > My schedule**
in the web dashboard. Choose which items to include and disconnect at any time.

### Serving Invitations and Responses

When a church organizer calendar is connected and a member opts into serving
sync with the same calendar provider, the church can send a calendar invitation
to the member's connected account. Declining that invitation updates the
serving response in TheFaithApp after synchronization.

A personal calendar copy is an appointment, so it does not provide an organizer
RSVP. Use the assignment's TheFaithApp response link, or respond in the
**Volunteer Hub**, when there is no church organizer invitation. The private
response link opens your assignment's role, date, time, timezone, and location
without requiring a staff account. Choose **Accept assignment**, or enter a
**Reason for declining** and choose **Decline assignment**. Your serving leader
can see your decline reason. Opening the page does not change your response.

After accepting, you can still decline if your plans change. Once declined,
contact your serving leader if you need to change the response again. If the
link has expired or the invitation is no longer available, review your schedule
in the **Volunteer Hub** or contact your serving leader.

Keep the response link private: anyone who has it can respond to that
assignment. Removing a calendar entry is not a decline.

### Check a Connection

Review the last successful sync and recent run results before retrying. Select
**Sync now** to request another run. Reconnect when authorization has expired
or been revoked by the calendar provider. Provider delays can mean a response
does not appear immediately.

Disconnecting stops future synchronization and tries to remove the entries
created by this connection before revoking access. If provider access has
already expired, some entries can remain; remove them in the calendar if
needed. Private calendar subscriptions remain available for read-only calendars.

## Event Registration Setup

Use event registration when attendees need to confirm participation before the event date.

![Event registration settings](https://mintcdn.com/thefaithltd/uLYp005rAsK2J5Ev/images/product/events-volunteers/event-registration-settings.png?fit=max\&auto=format\&n=uLYp005rAsK2J5Ev\&q=85\&s=14eb8ad32f46472474224828d5c02882)

### What You Can Set

* Whether registration is required
* Built-in registration or an external registration link
* Registration capacity
* Registration deadline
* Contact person name and email
* A fee per person or per registration
* A waitlist when an occurrence reaches capacity
* Meal count, childcare count, and special-note questions
* Reminder times before the event
* The member self-check-in window

### Steps

1. Open `Events`.
2. Create a new event or edit an existing one.
3. Turn on `Registration Required`.
4. Choose the registration type.
5. Add the capacity if you want to limit attendance.
6. Turn on the waitlist if people should still be able to join after the available places are filled.
7. Add a registration fee and currency when the event is paid.
8. Choose any extra information your team needs, such as meals, childcare, or special notes.
9. Add reminder times in minutes before the event. For example, `1440, 60` sends reminders one day and one hour before it starts.
10. Choose when member self-check-in opens and closes.
11. Set the registration deadline and contact person.
12. Save the event.

### Notes

* Built-in registration is best when you want attendance managed inside the platform experience.
* Use an external registration link if your church already relies on another signup tool.
* Paid registration becomes available after the church completes Stripe setup.
* Capacity counts the person registering and every additional guest in their party.
* When a registration is cancelled, the earliest waitlisted party that fits the available places is promoted automatically.

## Public Event Pages

A public event page gives guests an unguessable link they can open without signing in.

![Public event page](https://mintcdn.com/thefaithltd/uLYp005rAsK2J5Ev/images/product/events-volunteers/public-event.png?fit=max\&auto=format\&n=uLYp005rAsK2J5Ev\&q=85\&s=1644645b09b4862199b3f2fe381ce1ab)

### Share an Event

1. Create or edit the event.
2. Turn on `Public event`.
3. Save the event.
4. Select the event in the calendar or list to open its details drawer.
5. Select `Copy public link`.
6. Open the copied link once before distributing it.

The public page shows the event details, future occurrences, location, capacity, price, and only the registration questions enabled for that event. Paid guests continue through secure Stripe Checkout. A paid guest who moves off a waitlist can reopen the private registration link in their update email and continue payment.

## Manage Attendees and Check In

Select an event in the calendar or list, then open `Registrations` or `Check-in` in its details drawer.

![Event attendee and check-in workspace](https://mintcdn.com/thefaithltd/uLYp005rAsK2J5Ev/images/product/events-volunteers/event-attendees.png?fit=max\&auto=format\&n=uLYp005rAsK2J5Ev\&q=85\&s=b5e9dac8d25c330654115cb019eca689)

### What You Can Review

* Registered and waitlisted people
* Total occupied places, including guests
* Checked-in attendance
* Meal and childcare totals
* Payment state
* Special notes

### Work With an Occurrence

1. Open the `Registrations` tab in the event details drawer.
2. Choose the occurrence date.
3. Select `Load occurrence`.
4. Review the totals and attendee list.
5. Select `Check in` as people arrive, or switch to the `Check-in` tab for a focused check-in desk.
6. Cancel a registration only after confirming the attendee's request.
7. Select `Export` to download the occurrence list as a CSV file.

Members can also check themselves in from the mobile app during the event's configured check-in window. Staff check-in remains available outside that member window when an authorized team member needs to help at the door.

![Mobile event details and self check-in](https://mintcdn.com/thefaithltd/uLYp005rAsK2J5Ev/images/product/events-volunteers/mobile-event-detail.jpg?fit=max\&auto=format\&n=uLYp005rAsK2J5Ev\&q=85\&s=3c937cbb7c62453d99d790c1600bcc7c)

## Member Registration in the Mobile App

Members can open `Events` from `Quick actions` on the mobile Home screen, then:

* Browse an agenda or calendar
* Open event details and add the event to their calendar
* Register themselves and additional guests
* Enter meal, childcare, and special-note information when requested
* Pay securely in the app for paid events
* Review `My registrations`
* Open a registration to see its current status, party needs, payment, reminders, and check-in timing
* Cancel a registration
* Check themselves in during the event window
* Share a public event

Event reminders and waitlist updates open the referenced event in the mobile app. If the event cannot be loaded, the app falls back to the Events list. A registration that still needs payment remains clearly marked so the member can safely resume checkout.

![Mobile registration details](https://mintcdn.com/thefaithltd/uLYp005rAsK2J5Ev/images/product/events-volunteers/mobile-registration-detail.jpg?fit=max\&auto=format\&n=uLYp005rAsK2J5Ev\&q=85\&s=843622d8bd97643d2c361b6a102af9da)

## Volunteer Ministries

Use Volunteer Ministries to group opportunities under larger service teams.

![Volunteer ministries screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/events-volunteers/volunteer-ministries.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=4e539f0f48b243b166de76f21b7f510e)

### What You Can Do

* Create a ministry
* Add a short description
* Search ministries
* Review how many opportunities belong to each ministry
* Edit or delete ministries

### Steps

1. Open `Volunteers`.
2. Select `Ministries`.
3. Click `Add Ministry`.
4. Enter the ministry name and description.
5. Save the ministry.

## Volunteer Categories

Use Volunteer Categories to organize opportunities by type of service.

![Volunteer categories screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/events-volunteers/volunteer-categories.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=b3219e4066257efaceefb5b39fbf3675)

### What You Can Do

* Create categories for different service areas
* Search categories
* Review opportunity counts by category
* Edit or delete categories

### Steps

1. Open `Volunteers`.
2. Select `Categories`.
3. Click `Add Category`.
4. Enter the category name and description.
5. Save the category.

## Volunteer Skills

Use Volunteer Skills to track the abilities that can be matched to volunteer opportunities.

![Volunteer skills screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/events-volunteers/volunteer-skills.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=471aa9b1a56ade4447381aef90eec136)

### What You Can Do

* Create a skill
* Describe what the skill is used for
* Search skills
* Review how many opportunities and members are linked to each skill
* Edit or delete skills

### Steps

1. Open `Volunteers`.
2. Select `Skills`.
3. Click `Add Skill`.
4. Enter the skill name and description.
5. Save the skill.

## Volunteer Opportunities

Use Volunteer Opportunities to publish open serving roles and manage needed capacity.

![Volunteer opportunities screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/events-volunteers/volunteer-opportunities.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=6f3965caf3f325d22a68f0625c797847)

### What You Can Do

* Create a new opportunity
* Assign it to a ministry and category
* Set location, date, and time
* Define how many volunteers are needed
* Require approval before a signup is accepted
* Filter by ministry, category, or status
* Open signup requests for review
* Edit or delete opportunities

### Opportunity Details

* Title and description
* Ministry
* Category
* Location
* Date and time
* Volunteer slots needed
* Status
* Approval requirement

### Steps

1. Open `Volunteers`.
2. Select `Opportunities`.
3. Click `Add Opportunity`.
4. Enter the opportunity details.
5. Choose the ministry and category if needed.
6. Set the date, time, and location.
7. Add the number of volunteer slots.
8. Turn on approval if your team wants to review requests first.
9. Save the opportunity.

### Notes

* Opportunity cards show the number of filled and open volunteer spots.
* Active opportunities are easier for team leads to review from one page.

## Volunteer Signups

Use the signups drawer to review volunteer requests for a specific opportunity.

![Volunteer signups drawer](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/events-volunteers/volunteer-signups.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=89d18b71a742d863c64a5ed018603080)

### What You Can Do

* Review incoming signups
* Filter signups by status
* Approve or reject pending requests
* Remove a signup when needed

### Steps

1. Open `Volunteers`.
2. Select `Opportunities`.
3. Find the opportunity you want to review.
4. Click `View Signups`.
5. Use the status filter if you want to narrow the list.
6. Approve or reject pending requests from the actions column.

### Notes

* Opportunity cards show the current signup count before you open the drawer.
* Approval-based workflows are useful when volunteer roles have limited spaces or need team-lead review first.


# Forms
Source: https://docs.thefaithapp.com/product/forms

Create church forms, publish them on the web or member app, and turn every response into an organized follow-up workflow.

# Forms

Forms gives your church one place to create flexible forms, share them, and
coordinate what happens after someone responds. Use Forms for connection cards,
ministry interest, membership next steps, feedback, pastoral requests, internal
requests, and other church workflows that do not belong to a specialized
product.

Each response stays attached to the exact version of the form that the person
completed. Your team can assign an owner, set a due date and priority, add
private notes, and keep an activity history without moving the response into a
separate spreadsheet.

![Forms library](https://mintcdn.com/thefaithltd/OUU7GQw1uxz3I73Y/images/product/forms/forms-library.png?fit=max\&auto=format\&n=OUU7GQw1uxz3I73Y\&q=85\&s=9dc21fbc3b06b7abe822b318292e5a76)

## Before You Start

Make sure that:

* At least one administrator has permission to manage Forms.
* Staff who will review responses have response access.
* Sensitive or restricted forms have named form managers.
* The church's privacy wording and follow-up owner are agreed before publishing.
* Any custom domain you want to use is already connected in TheFaithApp.

> [!WARNING]
>
> Forms may contain pastoral, child, safeguarding, health, or other sensitive
> information. Collect only what your church needs, choose the correct
> sensitivity, and give response access only to the people responsible for the
> follow-up.

## Open Forms

1. Open the main product menu in the admin sidebar.
2. Select **Forms**.
3. Choose **All Forms**, **Responses**, or **Templates**.

Forms is a top-level product. **Donor Forms** remains inside **Outreach
Campaigns** and is a separate fundraising workflow.

## Create a Form

From **All Forms**, select **Create form** to start with an empty form, or
select **Browse templates** to start with reviewed questions and settings for a
common church workflow.

![Church form templates](https://mintcdn.com/thefaithltd/OUU7GQw1uxz3I73Y/images/product/forms/forms-templates.png?fit=max\&auto=format\&n=OUU7GQw1uxz3I73Y\&q=85\&s=84a849782d6721b9ac3b2bb586f49bca)

The template catalog includes starting points for:

* General contact and connection cards.
* Baptism and membership interest.
* Volunteer interest and applications.
* Small-group interest.
* Child dedication and pastoral appointments.
* Prayer requests and praise reports.
* Event feedback and facility requests.
* Annual member-information review.
* Communication preferences and testimony submissions.

Templates are editable starting points. Review every question, privacy notice,
access choice, sensitivity, and manager before publishing.

> [!TIP]
>
> Start with the shortest form that can support the next action. A clear form
> with fewer questions is usually easier to complete and easier for staff to
> follow up.

## Build the Form

The builder has three working areas: available blocks on the left, the form
canvas in the middle, and settings for the selected block on the right.

![Forms builder](https://mintcdn.com/thefaithltd/OUU7GQw1uxz3I73Y/images/product/forms/forms-builder.png?fit=max\&auto=format\&n=OUU7GQw1uxz3I73Y\&q=85\&s=27a046ebf12f3e28c2b2ede57dc64323)

### Add Questions

Select a block to add it to the form:

* **Short answer** for a name or brief response.
* **Long answer** for a message, story, or explanation.
* **Email address** and **Phone number** for contact details.
* **Number** and **Date** for structured values.
* **Single choice**, **Multiple choice**, and **Dropdown** for defined options.
* **Consent** for a clear acknowledgement or permission choice.

Use **Heading**, **Paragraph**, **Divider**, and **Section** to organize longer
forms without collecting an answer.

### Configure a Question

Select a question on the canvas, then review its settings. Depending on the
question type, you can:

* Change the label, help text, and placeholder.
* Make the question required.
* Set minimum or maximum limits.
* Add a custom validation message.
* Mark the answer as standard, sensitive, or restricted.
* Map an eligible answer to a member-profile field for staff review.
* Choose whether the answer may appear on the confirmation screen.

Drag blocks to reorder them, or use the up and down controls for keyboard
reordering. Duplicate a block when several questions need similar settings.

Profile mapping never silently replaces a member's saved details. A matching
response can create a proposed change for an authorized staff member to review.

For a consent question that asks for a reply, enable **Require an email or phone
number when checked** and include at least one email or phone question. The
connection-card template enables this automatically. Visitors can leave contact
details blank when they do not request a reply; asking for contact requires a
usable reply channel. When contact details are missing, the form highlights a
contact field and brings it into view so the visitor can correct it.

## Configure Access, Privacy, and Managers

Select **Settings** in the builder.

![Form access and privacy settings](https://mintcdn.com/thefaithltd/OUU7GQw1uxz3I73Y/images/product/forms/forms-settings.png?fit=max\&auto=format\&n=OUU7GQw1uxz3I73Y\&q=85\&s=969714383181198d128756d21eaeb3eb)

### Choose Who Can Open the Form

* **Public** allows anyone with the link to respond.
* **Member aware** remains public and can safely prefill verified member details
  after sign-in.
* **Member only** requires a verified church member.
* **Invite only** requires a valid invitation.
* **Restricted** is intended for tightly managed or sensitive collection.

You can also decide whether a verified member may respond for themselves, an
authorized adult in their household, or a child in their household. Child
responses require guardian attestation and restricted handling.

### Review Form Settings

The settings dialog also controls:

* Overall sensitivity.
* Whether one person may respond more than once.
* Privacy and confirmation wording.
* Opening and closing times.
* A total response limit.
* Form color and the message shown after closure.
* The staff members or permission groups responsible for the form.

Restricted forms should always have explicit managers. Managers can be used to
limit response access and receive response notifications without opening the
answers to every administrator.

A standard public form can be saved without selecting a manager. Settings and
manager choices save together; if something needs correction, the settings
dialog shows the error and keeps your choices available.

## Preview and Publish

Changes save to the current draft while you work.

1. Select **Preview** to review the draft without accepting a submission.
2. Check required questions, choice options, privacy wording, and confirmation
   text.
3. Select **Publish** or **Publish update**.
4. Confirm the version that will become public.

Publishing creates an immutable version. Later edits create a new draft, while
the public form continues using the last published version. Select **Versions**
to review the version history.

This keeps older responses understandable after a question is renamed,
reordered, or removed.

## Share the Form

Select **Share** after publishing.

![Form sharing options](https://mintcdn.com/thefaithltd/OUU7GQw1uxz3I73Y/images/product/forms/forms-sharing.png?fit=max\&auto=format\&n=OUU7GQw1uxz3I73Y\&q=85\&s=eb07f0a108a6500be93dce6b9011329b)

You can:

* Copy the public link.
* Download a QR code.
* Copy website embed code.
* Open the form in a new tab.
* Share the form through WhatsApp.

When the church has a connected custom domain, the public link, QR code,
WhatsApp link, and embed code use it automatically.

### Embed a Form on a Website

1. Copy **Website embed**.
2. Paste the complete code into a website block that accepts custom HTML or an
   iframe.
3. Publish the website page.
4. Test the page on a phone and computer.
5. Submit one test response and confirm that it appears in **Responses**.

Do not change the address inside the supplied iframe. If the form is long, the
website manager can increase the iframe height while keeping the form address
unchanged.

## Check the Public Experience

Open the public link before sending it to anyone.

![Published public form](https://mintcdn.com/thefaithltd/OUU7GQw1uxz3I73Y/images/product/forms/public-form.png?fit=max\&auto=format\&n=OUU7GQw1uxz3I73Y\&q=85\&s=6730bc2baa2d2503fc971336362c8825)

Confirm that:

* The church name, form title, description, and color are correct.
* Required questions and validation messages are clear.
* The privacy notice explains how the answers will be used.
* The form works at phone and desktop widths.
* The confirmation message gives the respondent a useful next step.
* Scheduled opening, closing, and response limits behave as expected.

Public submissions include duplicate and spam protections. If a connection is
interrupted, the respondent can retry safely without creating an extra response
from the same submission attempt.

## Deliver Forms in the Member App

Select **Delivery** to manage invitations, app placements, and connected
product actions.

### App Placements

A published form can be placed in a reviewed area of the member app through App
Customization. Members see the same published questions and validation rules as
the web form.

### Invitations and Reminders

Invite a member when the form should be delivered directly rather than shared
as a general public link. The delivery record shows whether the invitation was
queued, sent, opened, started, submitted, declined, or expired.

Reminders use the original delivery channel and respect the member's messaging
preferences. Avoid repeatedly reminding someone about a sensitive form.

## Review Responses

Open **Forms → Responses** for the global inbox, or open a form and choose its
responses view.

![Forms response inbox](https://mintcdn.com/thefaithltd/OUU7GQw1uxz3I73Y/images/product/forms/responses-inbox.png?fit=max\&auto=format\&n=OUU7GQw1uxz3I73Y\&q=85\&s=cdab5fe7ddf0bd0c2cfc837f38f7d6fa)

Use the inbox to:

* Search respondents and answers.
* Filter by form, status, priority, owner, and submission date. Use **Submitted
  from** and **Submitted to** for the start and end dates.
* Show current or historical answer columns.
* Choose visible columns.
* Save a useful filter as a view. Give it a **View name**, then select **Save
  view** or press Enter. The view restores your filters and visible columns.
* Export the authorized view to CSV.

On phones, each response appears as a readable card with its submitted time,
status, priority, form, respondent, owner, and selected answer columns. Select a
card to open the full follow-up view. On larger screens, the same information is
available in the response table.

One row is always one submission. Repeated responses from the same person stay
separate instead of being merged.

Sensitive answers are hidden or redacted for staff who do not have permission
to see them. Export uses the same access rules as the inbox.

## Assign and Complete Follow-Up

Select a response row or mobile card to open its details.

![Response details and follow-up](https://mintcdn.com/thefaithltd/OUU7GQw1uxz3I73Y/images/product/forms/response-details.png?fit=max\&auto=format\&n=OUU7GQw1uxz3I73Y\&q=85\&s=767dd14cc698bfcac3ba0738ef80abf3)

From the response details, authorized staff can:

* Change the workflow status.
* Set normal, high, or urgent priority.
* Set **Assigned to** and **Follow-up due**, then select **Save follow-up**.
* Review the answers against the submitted version.
* Add private staff notes.
* Review the activity history.
* Review a proposed member-profile change.
* See whether a connected product action completed or needs attention.

Use the owner and due date to make the next responsibility clear. Notes and
activity are internal and are not shown to the respondent.

## Connect a Response to Other Products

Forms can start reviewed actions for supported workflows such as visitor
follow-up, member journeys, events, volunteer coordination, Community Groups,
prayer requests, or an Outreach Campaign review reference.

Configure actions from **Delivery** and review the target before activating
them. Each action is recorded against the response so staff can see whether it
completed, failed, or is waiting for review. A failed action does not remove the
original response.

Forms does not copy submissions into the legacy Donor Forms tables. A future
fundraising or donor-data transfer must be separately reviewed and explicitly
configured.

## Close, Archive, Restore, or Delete

* **Close form** stops new responses while keeping the form and its history.
* **Reopen form** returns a closed form to its published state.
* **Archive** removes the form from the active workflow without deleting its
  history.
* **Restore** returns an archived form.
* **Delete draft** is available only when a draft can be safely removed.
* Moving a response to trash is recoverable by an authorized manager.

Do not delete or archive a form simply to hide sensitive data. Follow the
church's retention and safeguarding policy.

## Permissions and Privacy

Guest responses can display a supplied name when the name question is mapped
to **Name** and you have permission to see that answer. A guest is not linked
to a member automatically. Responses with no visible name or contact details
retain the anonymous label; sensitive answers remain protected.

Forms separates permission to build forms from permission to review responses.
Sensitive-answer access and form-manager restrictions narrow access further.

Recommended practice:

* Give form-building access only to staff who design church workflows.
* Give response access only to staff who own follow-up.
* Name managers for pastoral, child, safeguarding, or other restricted forms.
* Avoid collecting financial card data, passwords, government identifiers, or
  information that belongs in a specialized product.
* Review CSV exports before sharing or storing them outside TheFaithApp.
* Confirm consent before sending reminders or starting a connected action.

## Launch Checklist

Before sharing a new form:

* [ ] Preview every question and content block.
* [ ] Confirm access mode, sensitivity, and managers.
* [ ] Review privacy and confirmation wording.
* [ ] Publish the intended version.
* [ ] Open the public or member-app form yourself.
* [ ] Test phone and desktop layouts.
* [ ] Submit a test response.
* [ ] Confirm ownership, priority, due date, and notifications.
* [ ] Confirm any connected action reaches the expected product.
* [ ] Remove or complete the test response according to your retention policy.

## Current Limitations

The current release does not yet include nested conditional logic, multi-page
branching, partial submissions, file uploads, electronic signatures, payments,
calculations, webhooks, or direct spreadsheet integrations.

Use the existing specialized Giving, Events, Prayer Requests, Visitor, and
Outreach Campaign workflows when they already match the church's need.

## Common Questions

### Are Forms and Donor Forms the same?

No. Forms is a general church workflow product. Donor Forms remains part of
Outreach Campaigns and uses separate data and fundraising workflows.

### Does editing a form change old responses?

No. Each response stays attached to the published version that was submitted.

### Can a form use our custom domain?

Yes. Once the domain is connected, generated public and embed links use it
automatically.

### Can someone submit without an account?

Yes, when the access mode is **Public** or **Member aware**. Member-only,
invite-only, and restricted forms apply their selected access checks.

### Does profile mapping immediately update a member?

No. Eligible changes are presented for authorized staff review.

### Can every administrator see sensitive answers?

No. Response permission, answer sensitivity, and form-manager restrictions are
enforced separately.


# Free church tools
Source: https://docs.thefaithapp.com/product/free-church-tools

Prepare church text messages and a visitor follow-up plan without creating an account.

TheFaithApp’s [free church tools](https://thefaithapp.com/tools) help your team
prepare useful messages and plan a warm welcome. You can use them without an
account.

Choose **Review example drafts** to see the resource before entering any details.
Personalizing it is optional. Blank fields keep placeholders for your team to
replace before using the messages.

Use the language menu at the top of the page to choose **Español** or
**Français**. The examples and instructions use **\[Nombre]** in Spanish and
**\[Prénom]** in French for the visitor’s first name. Replace that placeholder
before sending. Copy or download your current drafts before changing language;
the language link opens a new page and does not carry over your details or edits.

## Personalize a church text message

1. Open [Church SMS templates](https://thefaithapp.com/tools/church-sms-templates).
2. Choose **Review example drafts** to read the available messages.
3. Choose a message occasion and, if useful, add your church name, event details,
   and an information link.
4. Review and edit a message directly in its draft box to make it sound like your
   team.
5. Choose **Copy templates** to copy all messages currently shown, including your
   edits and review reminders, or **Download templates** to save the same text.
   Choose **Copy message** if you only need one draft.

Templates cover visitor welcomes, events, service reminders, volunteers, member
care, small groups, and giving thanks. Replace **\[First name]** and any remaining
brackets before sending. Use your messaging provider’s opt-out instructions.

## Prepare a visitor follow-up plan

1. Open the [Church visitor follow-up planner](https://thefaithapp.com/tools/church-visitor-follow-up).
2. Choose **Review example drafts** to see the first-week plan.
3. Choose **Text message** or **Email**. If useful, add your church name, sender,
   follow-up owner or team, next service time, and visitor information link.
4. Review the first-week steps and edit the message drafts. Email drafts include
   an editable subject.
5. Choose **Copy plan** or **Download plan** to keep the complete resource:
   timing, follow-up owner, edited messages, email subjects when selected,
   team notes, and review reminders.

The plan starts with a thank-you, offers optional next steps and an invitation,
and finishes with an internal team review. Adapt it to the guest’s contact
preferences. A personal reply takes priority over another generic message.

The worked example shows how an email-permitted group inquiry can pass from a
welcome owner to a group leader. Agree what may be shared, who accepts the next
action, and when the team will check the outcome. Practise with fictional details;
record actual visitor information and staff assignments in your church’s records.

If automatic copying is unavailable, the tool shows the complete resource as
selectable text so you can copy it yourself. Downloads are text files you can
share with your team.

## Keep your edits while personalizing

Changing details or opt-out text updates message text and email subjects you
have not edited. Your edited wording stays as you wrote it, and switching
message occasions keeps your edits. Review any retained wording after changing
details, especially names, dates, links, and opt-out instructions.

The visitor planner keeps separate **Text message** and **Email** drafts.
Switching formats brings back the wording you edited for that format, including
email subjects. Edited team tasks stay the same in both formats.

* Choose **Restore generated draft** on a card to replace its current draft
  with wording based on your latest details. For an email, this restores both
  its subject and message. For a team task, it restores the task text.
* Choose **Reset details** to start again with the example drafts.
  If you have edited any draft, the tool asks you to confirm before clearing
  all text and email edits, email subjects, and team tasks. Cancel to keep your
  details and edits.

## Use the drafts with your church

These tools prepare drafts; they do not send messages, create visitor records,
or schedule follow-up. Your entered details and draft edits stay in the page and
are not saved by the tool. Copy or download them before leaving or reloading.

In TheFaithApp, you can use the text drafts in [Marketing](/product/marketing)
after setting up your SMS provider and subscribers. Use the
[new visitor journey](/product/new-visitor-journey) to coordinate actual visitor
records and follow-up.

JavaScript is needed for personalization, copy buttons, and downloads. The
example drafts remain available to read and select if JavaScript is disabled.


# Giving
Source: https://docs.thefaithapp.com/product/giving-and-finance

Review received gifts and payment attempts, manage recurring gifts and funds, and configure giving providers in TheFaithApp.

# Giving

Giving is a root product for receiving gifts, reviewing payment activity,
managing recurring gifts, and organizing funds. It keeps charitable giving
separate from the subscription billing your church uses to pay TheFaithApp.

These tools include:

* Donations
* Recurring donations
* Funds
* Public donation links
* Payment providers
* Received, pending, failed, and cancelled payment status
* Gift acknowledgements and delivery history
* Period and year-end giving statements
* Manual gift batches, deposit reconciliation, and finance approvals
* QuickBooks and Xero accounting export profiles, previews, and history
* Church-authorized QuickBooks and Xero connections for live account selection
  and balanced journal delivery
* Campaign goals, member pledges, reviewed impact updates, and annual reports
* Relational sponsorship and moderated letters
* QuickBooks reconciliation sync
* Time, presence, professional, Legacy Letter, and in-kind generosity tools

## Before You Start

* Sign in to your admin account.
* Open `Giving` from the product menu or left sidebar for gift activity and
  funds.
* Open `Settings` for payment providers, billing plans, payment methods, and AI billing.
* Some billing or payment actions depend on the payment providers already connected to your account.

## Donations Overview

Use the overview tab to monitor received gifts across the payment currencies
already active in your church account. Pending, failed, and cancelled payment
attempts do not increase these totals.

![Donations overview](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/giving-finance/donations-overview.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=a76554889746247a5c18979966e35a14)

### What You Can Do

* Review received gifts by currency
* Compare this month and this week at a glance
* See the average donation amount
* Use the overview before exporting or reviewing individual gifts

### Steps

1. Open `Giving`.
2. Stay on the `Overview` tab.
3. Review the cards for each available currency.
4. Switch to the other tabs when you need deeper detail.

## Donation Records

Use the donations list when you need to search, review, or export individual giving records.

![Donations list](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/giving-finance/donations-list.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=1c76bf146e6d47f692a267abb38ea2a6)

### What You Can Do

* Search donations by donor details or reference
* Filter records by received, pending, failed, or cancelled status
* Filter donations by date range
* Review gift amount, reason, method, status, and date
* Open an individual donation record
* Review general and Outreach Campaign gifts together while keeping their
  source visible
* See gift, gross, fees, refunds, disputes, and net settlement separately
* Record an audited correction or reversal when authorized
* Export a provider-neutral finance file with allocations, fees, settlement,
  and deposit fields

### Steps

1. Open `Giving`.
2. Click the `Donations` tab.
3. Use search, status, or the date range filter to narrow the list.
4. Review the donation rows.
5. Click the view icon when you need the full donation details.
6. Click `Export` when you want to download the current set of records.

### Notes

* Exports include received gifts by default. Pending, failed, and cancelled
  attempts stay out of finance totals and ordinary exports.
* Donation rows show both the payment method and payment status.
* A received gift cannot be edited or deleted in place. Authorized finance
  staff submit a reasoned correction or reversal instead. A different
  authorized person must approve it before the value changes, and the original
  record remains visible in the audit trail.
* Access to donor details, exports, manual entries, recurring support, funds,
  adjustments, statements, reconciliation, and provider settings can be
  granted separately.

## Public Donation Links

Use the donation link tool when you want to share a direct public giving page outside the admin dashboard.

![Donation link modal](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/giving-finance/donation-link-modal.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=17883eeb1b6b8311d0201a0f194c24d2)

### What You Can Do

* Generate a public giving link
* Copy the direct donation page URL
* Copy embed code for websites or landing pages

### Steps

1. Open `Giving`.
2. Click the `Donations` tab.
3. Click `Generate Donation Link`.
4. Copy the link or embed code you want to share.
5. Send the link to members, supporters, or website managers.

### Notes

* The generated link opens a secure public giving experience for your church.
* Use the embed option when you want the giving form placed inside another website.

## Public Giving Page

Use the public giving page when you want supporters to give through a church-branded page outside the admin dashboard.

![Public giving page](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/giving-finance/public-giving-page.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=4a1707651c50eee3fb24eecf1eaf588c)

### What Supporters Can Do

* Choose the available payment option
* Enter a donation reason and amount
* Decide whether to cover processing fees
* Review the payment summary before continuing

### Steps

1. Generate the public donation link from `Giving`.
2. Open the link to confirm the church branding and page title.
3. Share the link with supporters.
4. Ask supporters to sign in from the public page.
5. After sign-in, choose the payment option shown on the page.
6. Enter the donation purpose and amount.
7. Turn on `Cover Processing Fees` if the supporter wants to include them.
8. Review `Payment Summary` and continue to payment.

### Notes

* The screenshot above shows the public giving form after the supporter has already signed in.
* The current public giving experience starts with sign-in before the donation form appears.
* Connected payment providers control which payment options appear after sign-in.
* If the church has set a default payment provider, supporters may see only that option instead of multiple tabs.

## QR, NFC, and Text-to-Give Access

Open `Giving` and choose `Giving Access` when you want to share general giving
or a particular active fund without collecting payment details in a message.

### QR and NFC

1. Choose `General giving` or an active fund.
2. Copy the public URL, download the QR image, or download the NFC record.
3. Place the QR image in a reviewed church publication, or use a compatible NFC
   writing tool to write the `.ndef` URI record to a tag.
4. Scan or tap the finished asset before publishing it.

QR codes and NFC tags only open the church giving page. They do not start or
authorize a payment.

### Text-to-Give Links

Do not use text-message control commands as Giving keywords:

* `START`, `YES`, and `UNSTOP` can subscribe the sender to church text updates.
* `STOP`, `UNSUBSCRIBE`, `CANCEL`, `END`, and `QUIT` unsubscribe the sender.
* `HELP` and `INFO` return help instead of a giving link.

You cannot create or activate a Giving keyword with one of these words.
For an older reserved keyword, delete it and create a distinct replacement such
as `GIVE` or `BUILD`. You can also deactivate it if its other details are still
valid. Existing keywords are not changed automatically. Deactivating or deleting
a Giving keyword does not unsubscribe anyone or disable SMS control commands.

1. Confirm that the church's Twilio inbox is connected and signed webhooks are
   active.
2. Add a unique keyword, such as `GIVE` or `BUILD`.
3. Choose general giving or an active fund and set a short link-expiry window.
4. Optionally add a short introduction for the automated reply.
5. Publish the keyword together with the church's inbound SMS number.

A giving-link reply contains a signed, expiring link to the church giving
page. Receiving that reply does not create a gift, charge a payment method,
or subscribe the sender to church text updates. Marketing keywords and Giving
keywords cannot use the same word.

## Campaigns, Pledges, and Impact

Open `Giving` and choose `Campaigns & Impact` to extend an existing Outreach
Campaign with stewardship details. This keeps campaign content and financial
records connected without creating a second campaign system.

### Configure a Campaign Goal

1. Choose an active Outreach Campaign.
2. Select `General`, `Capital`, or `Missions` as the campaign type.
3. Add the monetary goal and its currency.
4. Choose the funding status and allocation policy.
5. Add a short current-phase label when the project has clear stages.
6. Keep public totals off until the church has reviewed the numbers and wants
   to publish them.
7. Save the campaign settings.

Received progress uses settled gifts only. Pledges and payment attempts do not
inflate the amount received. When public totals are off, public and member
campaign pages show the goal without revealing received or pledged totals.

### Member Pledges

Members can open a cash campaign in the app and choose `Make a pledge — no
charge`. They select an amount, commitment frequency, and optional reminder
cadence. An authorized adult primary household contact may choose household
roll-up and must confirm that authorization.

A pledge records voluntary intent. It does not charge a payment method,
schedule an automatic payment, or replace the normal giving checkout. Members
can review settled-gift progress, turn reminders off, or cancel the pledge
without changing gifts already received. If a member later chooses to give
toward the pledge, the regular provider checkout remains a separate step.

### Publish Impact Updates

1. Open the `Impact Updates` tab.
2. Choose a campaign or fund and the type of update.
3. Enter the title, display date, and update text.
4. Confirm documented subject consent before using a story or testimony.
5. Save the item for review.
6. Have an authorized reviewer approve and publish it.

Only reviewed, published updates appear on campaign, member, or public impact
pages.

### Annual Generosity Reports

Use `Annual Reports` to generate a year snapshot from settled gifts and
reviewed impact content. The report keeps currencies separate and does not
include donor identities. A draft stays private until an authorized user
publishes it, and a new version does not rewrite an earlier snapshot.

## Stock, Asset, and Legacy-Giving Inquiries

Members can request a private conversation with the authorized giving team
from `Pledges & impact` in the app. Staff review these requests under `Giving →
Campaigns & Impact → Stock & Legacy Inquiries`.

The inquiry is for information and follow-up only. Do not request or enter
asset values, brokerage or account numbers, passwords, private keys, copies of
wills, or other legal documents. TheFaithApp does not take custody of an asset
through this workflow.

## Relational Sponsorship

Open `Giving`, choose `Campaigns & Impact`, then open the broader generosity
tools. Authorized staff can create a sponsorship program and a masked
beneficiary profile. A minor cannot be added without recorded guardian consent.

Members choose a beneficiary in the Giving app and link an active recurring
gift. A different authorized person reviews the match before it becomes active.
Letters from either side are encrypted and wait for independent moderation.
Members may use AI to translate or lightly polish their own draft, but the
result is not saved or sent until they review it and submit it normally.

Progress updates also require documented consent and a different reviewer
before publication. Sponsor dashboards show settled support, approved updates,
and the masked beneficiary identity; private legal names and safeguarding
notes never appear there.

## Generosity Beyond Money

The same workspace helps a church coordinate generosity without treating every
contribution as money:

* **Micro-time** records small, bounded time commitments with a monthly cap.
* **Presence** uses a private invitation tied to a consented Pastoral Care
  relationship. Quiet relationships nudge only the assigned care owner.
* **Professional offers** require credential and scope review before approval.
* **In-kind needs** include a before-you-donate gate and clear pickup or
  delivery ownership.
* **Legacy Letters** remain member-controlled and encrypted. Clergy can open a
  released letter only after prior member consent, a funeral-care record, and a
  recorded death; every access is logged.
* **Non-financial statements** summarize only the member's own confirmed
  activity and are never a leaderboard, tax receipt, or measure of spiritual
  worth.

Anonymous benevolence intake is kept outside the member directory. A private
reply code shows the requester a safe status without exposing staff notes.

## Recurring Donations

Use recurring donations to review active scheduled gifts and confirm what supporters have set up to repeat automatically.

![Recurring donations](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/giving-finance/recurring-donations.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=cc6c5249e086b4d8ac7301395afa497b)

### What You Can Do

* Review active recurring gifts
* Search recurring donations
* See the fund, amount, frequency, method, and next payment date
* Identify retrying, paused, and action-required gifts
* Help a member pause, resume, or change the future amount, frequency, or fund
  in the mobile app
* Cancel a recurring donation when needed

### Steps

1. Open `Giving`.
2. Click the `Recurring` tab.
3. Search for a donor or recurring record if needed.
4. Review the next payment date and current status.
5. Use the action menu when you need to cancel an active recurring gift.

### Notes

* The recurring table is best for finance follow-up and supporter support requests.
* Status helps your team confirm whether a recurring gift is still active.
* Changes affect future scheduled gifts and never rewrite an earlier received
  gift.
* When a saved payment method cannot be recovered, Giving says that a payment
  method update is required instead of pretending the recurring gift resumed.
* PayPal recurring gifts can be paused, resumed, or cancelled from Giving.
  Changing their amount or schedule requires cancelling the current gift and
  approving a new one in PayPal.
* Recurring options depend on the connected provider's approval for automatic
  payments. Flutterwave card acceptance alone does not enable recurring gifts.
  Contact support if the expected recurring options are unavailable.

## Receipts and Acknowledgements

Every received general or Outreach Campaign cash gift can have an immutable
acknowledgement. The acknowledgement records the amount, currency,
designation, issue date, and each email delivery attempt.

1. Open `Giving`, then open a received gift.
2. Find `Receipts and acknowledgements`.
3. Review the issue and delivery history.
4. Use `Resend receipt` when an authorized recipient needs another copy.

Acknowledgements do not claim that a gift is tax-deductible unless your church
has separately configured and reviewed the required legal wording.

When a provider confirms a refund or dispute, Giving keeps the original
acknowledgement as superseded and issues a corrected version for the remaining
received amount. If no received amount remains, it marks the acknowledgement
voided. A successful dispute reversal reinstates the amount with a new current
version. Only the current issued acknowledgement can be resent.

## Mobile Checkout Safety

Closing a Stripe, PayPal, or Flutterwave payment screen does not complete a gift.
Giving records that the checkout was left and shortens its pending window,
while still allowing a valid provider confirmation that was already in flight.
If a card is declined, a later successful provider confirmation can complete
the same gift without losing its fee and settlement breakdown.

Flutterwave recurring giving appears only after Flutterwave has approved the
church account for automated tokenized card charges and the capability has
been enabled in TheFaithApp. Until then, members can make one-time Flutterwave
gifts without being offered a recurring schedule that the account cannot run.

PayPal uses a hosted approval screen for both one-time and recurring gifts.
Recurring choices appear only when the connected church has PayPal's partner
Subscriptions capability. After the member approves, the subscription belongs
to the church's PayPal account; PayPal collects each scheduled gift, manages
payment retries, and sends the result back to Giving. A gift is never created
against TheFaithApp's platform account.

## Funds

Use funds to control the giving categories donors can choose from.

![Funds screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/giving-finance/funds.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=5cc58abb9d7ed5a97d7d1dce92f80ad7)

### What You Can Do

* Create a fund
* Add a short description
* Mark a fund restricted, temporarily restricted, or unrestricted
* Set the one default fund and optional availability dates
* Turn a fund on or off
* Close a used fund without deleting its history
* Add an optional accounting code, account name, and class for finance export
* Search funds
* Edit or delete a fund

### Examples

* Building fund
* Missions
* General giving
* Youth ministry

### Steps

1. Open `Giving`.
2. Click `Funds`.
3. Click `Add Fund`.
4. Enter the fund name and optional description.
5. Save the fund.
6. Use the toggle or actions in the list when you need to update it later.

### Notes

* Active funds are available in the giving experience.
* Closing a fund requires second-person approval. Closed and inactive funds
  remain available for historical reporting without staying visible to donors.

## Giving Statements

Open `Giving` and choose `Statements` to prepare period or year-end statements
from received gifts. Pending, failed, cancelled, reversed, and otherwise
unsettled attempts are not included.

### Configure Statements

1. Review the church legal name, jurisdiction, registration details, address,
   and statement wording.
2. Keep the general wording factual. It should acknowledge gifts without
   promising a tax treatment that has not been legally reviewed.
3. Enable year-end statements only after the church has confirmed the required
   details and wording for its jurisdiction.
4. Save the settings before issuing a year-end statement.

### Issue and Deliver a Statement

1. Click `Issue statement`.
2. Select the member and reporting period.
3. Choose individual giving unless the household has explicitly authorized a
   household statement and the recipient is an authorized adult contact.
4. Review the per-currency totals and included gifts.
5. Download the PDF or send it to the authorized recipient.

Members can see only their own issued statements in the mobile app. They can
download a private PDF or ask the church to resend it to their recorded email
address.

### Corrections

An issued statement is never edited in place. Authorized staff enter a reason
for the correction, and a different authorized person approves or rejects the
new version. Approval supersedes the earlier version while keeping both in the
financial history. A statement waiting for approval is not available to the
member.

## Finance Operations

Open `Giving` and choose `Finance Operations` to prepare manual gifts and match
bank or provider deposits.

### Manual Gift Batches

1. Click `New batch` and enter an independent expected gift count and total.
2. Add each cash, check, or bank-transfer gift, including the donor's name and valid email address, amount, payment method, and fund allocation.
3. Confirm that the entered count and total match the declared controls.
4. Submit the batch with a control note.
5. A different authorized person reviews and closes the batch. Until then,
   its gifts remain pending and do not increase received-gift totals.

### Deposit Reconciliation

1. Click `New deposit` and copy the gross amount, processor fee, net amount,
   date, provider, currency, and reference from the deposit record.
2. Match received general or Outreach Campaign gifts by their Giving record
   ID.
3. Submit only when matched gift value equals the deposit gross amount.
4. A different authorized person reviews and closes the reconciliation.

Add the optional deposit account code and name when your accounting system
uses a clearing or bank account mapping. Fund account codes, account names,
and classes are available to accounting exports.

### QuickBooks and Xero Exports

You can prepare an accounting file without connecting TheFaithApp to an
accounting provider.

1. In `Finance Operations`, click `New export profile`.
2. Choose QuickBooks or Xero and give the profile a recognizable name.
3. Map the contribution, processing-fee, refund, and settlement accounts.
   QuickBooks uses the account names from your chart of accounts. Xero uses
   account codes.
4. Open `Giving` > `Funds` and add fund-specific accounting details where a
   fund should not use the profile's default contribution account.
   Reconciled deposits can also use their own accounting deposit account; that
   account takes priority over the profile's default settlement account.
5. Return to `Finance Operations`, choose the profile, date range, currency,
   and gift source, then click `Preview export`.
6. Review record and row counts, balanced debits and credits, warnings, and
   sample rows. Correct every validation error before continuing.
7. Click `Generate and download`. The completed file stays in export history
   so an authorized finance user can download the same file again.

The export contains settled gifts only and does not include donor names or
email addresses. Failed validation attempts remain visible with a correction
message but do not produce a downloadable file. Each currency is exported
separately.

QuickBooks files follow its journal-entry import fields. Xero files follow its
manual-journal import fields. Confirm the date format, chart of accounts, tax
rate, class or tracking setup, and import preview inside your accounting
product before posting the journal.

### Connect and Send to QuickBooks or Xero

An authorized finance user can connect the church's QuickBooks company or Xero
organization without leaving `Finance Operations`.

1. In the QuickBooks or Xero connection card, click `Connect`.
2. Sign in to the provider and choose the church-owned company or organization
   you intend to use. For Xero testing, choose the Demo Company.
3. Confirm the connection. The card shows the company name and whether the
   connection is using a test or production environment. Xero also shows the
   organization's base currency.
4. Create or edit an export profile for the connected provider. Choose each
   account from the connected chart of accounts instead of typing it manually.
   For Xero, choose a non-bank clearing account for settlement lines because
   Xero does not allow manual journals directly against bank accounts.
5. Preview the date range and correct every mapping, class, balance, or
   currency error. Xero manual journals must use the organization's base
   currency.
6. Click `Generate and send to QuickBooks` or `Generate and send to Xero`, or
   send a completed run from export history.
7. Confirm the sent status, then review the journal entries in the connected
   accounting product.

TheFaithApp sends one balanced journal per settled gift and uses the same
request identity when a delivery is retried. A completed run is not posted a
second time. Donor names and email addresses are not included in the
provider journal.

If an approved refund, dispute, or correction changes a gift after its journal
was sent, generate and send a fresh export. TheFaithApp posts a dated reversal
of the earlier journal followed by a corrected replacement journal. It never
silently edits the earlier provider record, and retrying an interrupted
correction does not duplicate the reversal.

Use `Disconnect` when the church no longer wants live delivery. Disconnecting
revokes that provider's authorization and removes the stored access tokens; it
does not delete earlier exports or accounting records. If authorization
expires, use the provider's `Reconnect` action before retrying a failed
delivery. Neither QuickBooks nor Xero needs to be connected to generate CSV
files.

Where both staff accounts can be linked to member households, the reviewer
must also be from a different household. Finance actions remain visible in the
approval history whether approved or rejected.

## Payment Providers

Use payment providers to connect the services your church will use to accept online gifts.

![Payment providers screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/giving-finance/payment-providers.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=adb78edbdc2e7c9ca8d07f4d0dc3dc86)

### Available Providers

* Stripe
* Flutterwave
* PayPal

### What You Can Do

* Connect a payment provider
* Disconnect a provider
* Set the default provider
* Turn on charitable PayPal fees where applicable
* Allow donors to cover processing fees
* Enable Stripe wallet or ACH rails when the connected account is eligible

### Steps

1. Open `Settings`.
2. Click `Payment Providers`.
3. Connect the provider you want to use.
4. Set a default provider if more than one is available.
5. Turn on `Cover Processing Fees` if your church wants to offer that option during giving.
6. Save or confirm any provider changes.

### Connect Stripe

Choose **Connect with Stripe** in Payment Providers. Stripe lets you sign in
and select an existing Standard account, or create a new Standard account.
Authorize TheFaithApp to complete the connection. Your church keeps its own
Stripe account and dashboard in either case.

If the connection option is unavailable, contact support to complete the
Stripe connection setup. There is no separate account-creation flow in
TheFaithApp. An unfinished connection shows **Resume connection**.

Stripe may still need information before your account can receive payments.
A pending connection stays unavailable for giving until Stripe confirms it
can accept charges and receive payouts. Open your Stripe dashboard to finish
any outstanding steps.

An account controlled by another platform may not be eligible to connect.
Existing connections are kept in place; connecting a different account does
not move Stripe customers, subscriptions, or payment history. Plan any
account change before disconnecting an account used for recurring gifts.

Disconnecting revokes TheFaithApp's access before removing the connection.
It does not delete your church's Stripe account. Some accounts have
platform controls and require your platform administrator to remove the
connection in the Stripe Dashboard. If that step is required, the connection
stays in place and the dashboard explains what to do next.

### Notes

* Stripe, Flutterwave, and PayPal can support different payment needs depending on your region and ministry setup.
* The default provider is the main option used when multiple providers are connected.
* Flutterwave accounts need separate approval for automated tokenized card
  charges before recurring Flutterwave giving can be enabled. One-time
  Flutterwave giving remains available without that capability.
* PayPal accounts can accept one-time hosted gifts. Recurring choices become
  available after the connected church has the partner Subscriptions
  capability enabled in TheFaithApp.
* Stripe ACH stays pending until Stripe reports settlement. Apple Pay and
  Google Pay appear only after the required merchant and domain configuration
  is active for the church and device.
* Fee covering uses the configured provider, rail, currency, percentage, and
  fixed component to estimate the gross amount needed for the intended gift.

## Billing and Subscription

TheFaithApp account billing is separate from Giving. Use the billing page under
`Settings` to manage the plan your church pays for, review recommended plans,
and keep subscription billing organized.

![Billing and subscription screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/giving-finance/billing-subscription.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=61e44baede2a934ed909c31fd5bd1f01)

### What You Can Do

* Review your current plan
* See the recommended plan based on member count
* Compare available plans
* Add and manage payment methods
* Review billing history

### Steps

1. Open `Settings`.
2. Click `Billing & Subscription`.
3. Review the current plan summary.
4. Compare the available plans below.
5. Click `Switch Plan` when you are ready to move to a different subscription tier.
6. Review the billing history section for past charges.

### Notes

* Recommended plans are based on the member count in your church account.
* The billing page also shows the products, feature access, and allowances for
  the current plan.
* Full data export remains available on every plan.
* A downgrade preserves existing records. Work above the new allowance becomes
  read-only after the applicable grace period rather than being deleted.

### How the Plans Differ

| Plan | Monthly price | Member capacity | Best fit |
| - | -: | -: | - |
| Free | \$0 | Up to 100 | Core church management with starter access across the wider suite |
| Standard | \$39 | Up to 500 | Giving, engagement, and formation for one church |
| Large | \$79 | Up to 1,500 | Multi-branch operations, governance, API access, and custom domains |
| Enterprise | From \$149 | 2,000 included | Church networks, expanded integrations, and guided support |

The Free plan includes people, households, groups, events, care, teaching
content, one branch, three staff administrators, and full export. It also
includes starter allowances for Giving, Forms, Marketing, Outreach, Children &
Youth, Discipleship, Analytics, Operations, and App Customization. The billing
page shows the exact allowance before a team reaches it.

Paid plans also use clear operating allowances instead of an open-ended
“unlimited” promise. Standard includes 10 administrators, 10 active Forms,
1,000 monthly Form responses, 5 monthly campaigns, and 10 active scheduled
reports. Large expands those limits for multi-branch ministry and includes up
to 5 active webhook endpoints. Enterprise expands capacity again, including
100 administrators, 20 branches, 50,000 monthly Form responses, and 25 active
webhook endpoints. Existing records remain available when a church reaches a
limit.

## Payment Methods

Use payment methods to add the card used for subscription billing and other paid add-ons.

![Add payment method drawer](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/giving-finance/add-payment-method.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=8795736bec7ab0af1a2dc5645fcd1437)

### What You Can Do

* Add a payment method
* Set a default card
* Remove a payment method when it is no longer needed

### Steps

1. Open `Settings`.
2. Click `Billing & Subscription`.
3. In `Payment Methods`, click `Add Payment Method`.
4. Enter the cardholder name and card details.
5. Save the payment method.

### Notes

* Add a payment method before activating paid add-ons or switching to paid plans.
* The billing page uses the saved payment methods section for subscription charging.

## AI Add-On Billing

Use the AI section on the billing page to manage access to the Digital Ministry Assistant add-on.

### What You Can Do

* Review free AI replies remaining
* Activate the AI add-on
* Choose whether members can use **Ask your church**
* See included, used, and remaining usage
* Cancel the add-on when needed

### Steps

1. Open `Settings`.
2. Click `Billing & Subscription`.
3. Find the `Digital Ministry Assistant` section.
4. Review the current status and usage totals.
5. Add a payment method first if required.
6. Click `Activate AI Add-on` when you are ready to continue with paid AI usage.
7. Turn on `Allow members to use Ask your church` if the church wants members
   to share the paid reply allowance.

### Notes

* The billing panel shows whether the AI add-on is active, inactive, past due, or canceled.
* Free usage can run out before activation is required, depending on the account state.
* Digital Ministry Assistant costs \$29 per month and includes 200 assistant
  replies each month, plus the included sermon and prayer-room AI tools.
* Member access is off by default, does not use the five-reply staff trial, and
  is limited to five questions per member per day.
* Member and staff replies draw from the same church-paid monthly allowance.
* Only billing administrators can change member access, and each change is
  recorded in the church's audit history.

## Prayer Rooms Plus Billing

Prayer Rooms Plus is an optional \$19 monthly add-on. It adds video rooms,
recordings, global rooms, advanced room controls, and the paid participant-minute
allowance without requiring the church to change its base plan.

Churches can try three advanced room sessions before upgrading. The billing page
shows trial usage, included minutes, used minutes, remaining minutes, and the
current add-on status.


# Marketing
Source: https://docs.thefaithapp.com/product/marketing

Manage marketing dashboards, Mailgun, Twilio, email campaigns, email templates, subscribers, and SMS outreach in TheFaithApp.

# Marketing

This guide covers the marketing tools used to manage email and SMS communication in TheFaithApp.

These tools include:

* Marketing dashboard
* Integrations
* Mailgun
* Twilio
* Email campaigns
* Email templates
* Email subscribers
* SMS campaigns
* SMS templates
* SMS subscribers

## Before You Start

* Sign in to your admin account.
* Open `Marketing` from the six-product sidebar, then choose `Dashboard`, `Email Marketing`, `SMS Marketing`, or `Integrations`.
* Use `Integrations` before building campaigns if your providers are not set up yet.
* New accounts may show empty states until your first template, subscriber list, or campaign is added.

## Marketing Dashboard

Use the dashboard to monitor the overall health of your email and SMS activity from one place.

![Marketing dashboard](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/marketing/marketing-dashboard.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=dc71542f19bd666f6ae4d2fc7442cae6)

### What You Can Do

* Review email campaign totals
* Review SMS campaign totals
* Check open, click, and delivery rates
* Monitor template and subscriber totals
* See scheduled campaign totals at a glance

### Steps

1. Open `Marketing`.
2. Stay on `Dashboard`.
3. Review the summary cards for email, SMS, templates, and subscribers.
4. Open the related marketing section when you want to take action on a specific area.

### Notes

* The dashboard is the best starting point for a quick daily review.
* Empty cards usually mean this area has not been configured or used yet.

## Integrations

Use integrations to connect the providers that power your email and SMS delivery.

![Marketing integrations](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/marketing/integrations.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=edb87455fb81130fbbd1b0d78b48954d)

### What You Can Do

* Open SMTP setup
* Configure Mailgun
* Configure Twilio
* Review which providers are already active

### Steps

1. Open `Marketing`.
2. Click `Integrations`.
3. Review the email and SMS provider cards.
4. Click `Configure` on the provider you want to update.

### Notes

* `SMTP Configuration` opens the general settings area for SMTP setup.
* Mailgun and Twilio can both be managed directly from this screen.

## Mailgun

Use the Mailgun drawer when your team wants Mailgun to handle email delivery.

![Mailgun configuration drawer](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/marketing/mailgun-drawer.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=21c90d5a0180f5995371b34de9c8c106)

### What You Can Do

* Enter your Mailgun API key
* Add the verified Mailgun domain
* Choose the Mailgun region
* Turn Mailgun on or off
* Set Mailgun as the default email provider

### Steps

1. Open `Marketing`.
2. Click `Integrations`.
3. In the `Mailgun Integration` card, click `Configure`.
4. Enter the provider details.
5. Turn on Mailgun if you want to use it for sending.
6. Save the settings.

### Notes

* Use the region that matches your Mailgun account.
* Set Mailgun as default only if it should be the main email sending service for your church.

## Twilio

Use the Twilio drawer when your team wants its church-owned Twilio account to
handle SMS, approved WhatsApp delivery, and the homebound phone companion.

> [!TIP]
>
> Complete the [Twilio setup guide](/product/twilio-setup) before enabling the
> provider. It covers number capabilities, trial limits, the incoming-message
> webhook, Voice geographic permissions, live QA, security, and billing.

![Twilio configuration drawer](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/marketing/twilio-drawer.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=3b83b2c383f192e8120c25908e6a7020)

### What You Can Do

* Enter the Twilio account SID
* Enter the auth token
* Add the sending phone number
* Turn Twilio on or off
* Set Twilio as the default SMS provider
* Copy the church-specific incoming-message webhook
* Test the saved credentials

### Steps

1. Open `Marketing`.
2. Click `Integrations`.
3. In the `Twilio Configuration` card, click `Configure`.
4. Enter the provider details.
5. Turn on Twilio when you are ready to send SMS campaigns.
6. Save the settings, then select `Test Connection`.
7. Copy the webhook URL and add it to the Twilio number's `A message comes in`
   setting with `HTTP POST`.

### Notes

* The phone number should be the number your church will send SMS from. It must
  also have Voice capability when the church uses the homebound phone
  companion.
* Set Twilio as default if it should be the main SMS provider for your account.
* The credential test does not send a message or place a call. Complete the
  live tests in the setup guide before launch.

## Email Campaigns

Use email campaigns to plan and manage email communication for members and subscribers.

![Email campaigns screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/marketing/email-campaigns.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=a68b33884b7c148033bc08068cc397ef)

### What You Can Do

* Search campaigns
* Filter by status
* Create a new campaign
* Review empty-state prompts when no campaigns exist yet

### Steps

1. Open `Marketing`.
2. Expand `Email Marketing`.
3. Click `Email Campaigns`.
4. Use search or status filters to narrow the list.
5. Click `Create Campaign` when you want to start a new email campaign.

### Notes

* This page is the main workspace for reviewing campaign status.
* New accounts will usually start with an empty state here.

## Creating an Email Campaign

Use the create drawer when you want to start a guided email campaign setup.

![Create email campaign drawer](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/marketing/email-campaign-create.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=9d825c276da5cda0043847a9bd491250)

### What You Can Do

* Enter campaign details
* Move through the guided setup steps
* Choose recipients
* Decide whether to send now or schedule later

### Steps

1. Open `Email Campaigns`.
2. Click `Create Campaign`.
3. Enter the campaign name, sender name, and sender email.
4. Continue through the content, recipients, schedule, and review steps.
5. Save or continue based on the campaign flow shown in the drawer.

### Notes

* The campaign builder uses a step-by-step flow to keep setup organized.
* Template loading and recipient totals are still limited in the current build, so treat this flow as in progress.

## Email Templates

Use email templates to prepare reusable layouts and messaging before creating campaigns.

![Email templates screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/marketing/email-templates.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=63cf63e413198fe4a301b13dc3ffd295)

### What You Can Do

* Create a template
* Filter templates by category
* Edit a template
* Duplicate a template
* Delete a template

### Steps

1. Open `Marketing`.
2. Expand `Email Marketing`.
3. Click `Email Templates`.
4. Use the category filter if you want to narrow the list.
5. Click `Create Template` to add a new reusable template.

### Notes

* Templates are helpful when your team sends similar messages often.
* Keep template names clear so campaign builders can choose the right one quickly.

## Creating an Email Template

Use the create template drawer when you want to prepare the structure of a new email before sending campaigns.

![Create email template drawer](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/marketing/email-template-create.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=0eb5049fbef0b886d877fb52efe474e2)

### What You Can Do

* Add a template name
* Choose a category
* Add the subject line
* Add optional preview text
* Move into the design tab for the email layout

### Steps

1. Open `Email Templates`.
2. Click `Create Template`.
3. Enter the basic template details.
4. Open the `Email Design` tab when you are ready to build the layout.
5. Save the template.

### Notes

* Preview text helps members understand the message before opening the email.
* Use categories to keep welcome emails, announcements, and follow-up templates organized.

## Email Subscribers

Use email subscribers to manage who can receive email communication from your church.

![Email subscribers screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/marketing/email-subscribers.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=5fffee4f105209c43357f93b83d4aa4e)

### What You Can Do

* Search subscribers
* Filter by status
* Filter by source
* Sync members into the subscriber list
* Import subscribers from CSV
* Unsubscribe, resubscribe, or delete subscribers
* Bulk unsubscribe or bulk delete selected subscribers

### Steps

1. Open `Marketing`.
2. Expand `Email Marketing`.
3. Click `Email Subscribers`.
4. Use search or filters to review the list.
5. Click `Sync Members` to pull member records into the subscriber list.
6. Click `Import Subscribers` if you want to upload a CSV file.

### Notes

* Source labels help your team tell whether a subscriber came from members, imports, or manual entry.
* Syncing members is useful after major membership updates.

## Importing Email Subscribers

Use the import drawer when you already have a CSV file of contacts to add.

![Import email subscribers drawer](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/marketing/email-subscribers-import.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=68e99f3cd58f61d9dfd8a763759d0d5b)

### What You Can Do

* Upload a CSV file
* Confirm whether the first row contains headers
* Import a batch of contacts in one step

### Steps

1. Open `Email Subscribers`.
2. Click `Import Subscribers`.
3. Select the CSV file.
4. Confirm whether the first row contains headers.
5. Click `Import Subscribers`.

### Notes

* CSV import is the fastest option when you already have contacts outside the platform.

## SMS Campaigns

Use SMS campaigns to prepare text message communication for members or subscriber groups.

![SMS campaigns screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/marketing/sms-campaigns.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=8a17ea8a2b8ea5f81355d7ea29587598)

### What You Can Do

* Search campaigns
* Filter by status
* Create a new SMS campaign
* Review the campaign list from one place

### Steps

1. Open `Marketing`.
2. Expand `SMS Marketing`.
3. Click `SMS Campaigns`.
4. Use search or status filters when needed.
5. Click `Create Campaign` to start a new SMS campaign.

### Notes

* SMS campaigns use a guided flow similar to email campaigns.

After sending, the campaign's **Delivered** count reflects successful sending
requests, not a final receipt showing that each text reached a phone. Check the
message's latest status in your church's Twilio Messaging logs; [Twilio's status
guide](https://www.twilio.com/docs/messaging/api/message-resource#message-status-values)
explains the difference. Even a delivery receipt does not show that someone read
the text or accepted an invitation. Record actual replies and next steps
separately, with someone responsible for follow-up.

## Creating an SMS Campaign

Use the create drawer when you want to build an SMS campaign step by step.

![Create SMS campaign drawer](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/marketing/sms-campaign-create.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=8481e14a0177917e778e0312747f600d)

### What You Can Do

* Enter campaign details
* Choose a saved SMS template
* Review recipient totals
* Schedule the campaign or send it immediately

### Steps

1. Open `SMS Campaigns`.
2. Click `Create Campaign`.
3. Enter the campaign name and optional sender ID.
4. Continue through message, recipients, schedule, and review.
5. Complete the campaign setup from the final step.

### Notes

* The SMS builder shows the campaign process in five clear steps.
* Recipient totals are calculated as you choose the audience.

### Check the Draft Segment Estimate

The message step estimates SMS segments from the text currently in the editor.
It distinguishes GSM-7 text from Unicode text, including emoji and curly quotes.
Some GSM-7 symbols use two units, so character count alone does not determine
how many segments a message needs.

Treat this as a **draft estimate**. A recipient's name, other personalized
values, an unsubscribe link and any added opt-out instruction can change the
finished message and its segment count. Review the complete text before sending.
Template editors use the same draft estimate.

The campaign review shows estimated draft segments across the selected audience.
It does not quote your provider's price. Sender type, destination, provider
settings and the final text can affect billing. Check your church's provider
account for applicable prices and actual message records. See
[Twilio's message-length guidance](https://www.twilio.com/docs/glossary/what-sms-character-limit)
for encoding limits and sender-specific exceptions.

## SMS Templates

Use SMS templates to save reusable message formats for future campaigns.

![SMS templates screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/marketing/sms-templates.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=7ce5129bc35555483f8609cb2e637825)

### What You Can Do

* Create a template
* Filter by category
* Edit a template
* Duplicate a template
* Delete a template

### Steps

1. Open `Marketing`.
2. Expand `SMS Marketing`.
3. Click `SMS Templates`.
4. Use the category filter when needed.
5. Click `Create Template` to add a reusable message.

### Notes

* SMS templates help teams move faster when they send recurring reminders or announcements.

## Creating an SMS Template

Use the create drawer when you want to save a new reusable SMS message.

![Create SMS template drawer](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/marketing/sms-template-create.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=80a196002bce6e28f4e504a80e1695bf)

### What You Can Do

* Add a template name
* Choose a category
* Write the SMS message
* Set the template active or inactive

### Steps

1. Open `SMS Templates`.
2. Click `Create Template`.
3. Enter the template name and category.
4. Write the message content.
5. Save the template.

### Notes

* Keep templates short and clear so they fit SMS comfortably.

## SMS Subscribers

Use SMS subscribers to manage the people who can receive text message communication from your church.

![SMS subscribers screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/marketing/sms-subscribers.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=326469a375ff7a74fa1cac4cbc7a2063)

### What You Can Do

* Search subscribers
* Filter by status
* Filter by source
* Send opt-in SMS to all pending contacts
* Sync members into the SMS list
* Import subscribers from CSV
* Send individual opt-in messages
* Confirm opt-in
* Unsubscribe or delete subscribers

### Steps

1. Open `Marketing`.
2. Expand `SMS Marketing`.
3. Click `SMS Subscribers`.
4. Use search or filters to review the list.
5. Click `Send Opt-In SMS (All Pending)` when you want to follow up with pending contacts.
6. Use `Sync Members` or `Import Subscribers` when you need to add more contacts.

### Notes

* SMS subscriber status is especially important because opt-in confirmation affects who can receive future messages.

## Importing SMS Subscribers

Use the import drawer when you already have a CSV file of phone contacts to add.

![Import SMS subscribers drawer](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/marketing/sms-subscribers-import.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=1e69ee52061c7d9de12d2e50dcbcbc23)

### What You Can Do

* Upload a CSV file
* Confirm whether the first row contains headers
* Import a batch of SMS contacts

### Steps

1. Open `SMS Subscribers`.
2. Click `Import Subscribers`.
3. Select the CSV file.
4. Confirm the header option.
5. Click `Import Subscribers`.

### Notes

* Import is useful when your church already has a separate SMS contact list.

## Current Product Notes

* `SMTP Configuration` is linked from `Marketing > Integrations`, but the actual setup screen opens in the general `Settings` area.
* The email campaign builder is visible and usable as a guided workflow, but template loading and recipient totals are still limited in the current build.
* Email campaign card `View` and `Edit` actions are not fully available yet in the current build.


# Member Connections and Community Groups
Source: https://docs.thefaithapp.com/product/member-connections

Help members connect with campuses, ministries, and community groups while keeping every relationship manageable and privacy-aware.

Member Connections gives people a clear picture of where they belong in your
church. Members can manage their campuses, ministries, and community groups
from the mobile app, while staff can review requests and keep those
relationships accurate from the web dashboard.

## For members

Open **My Connections** in the mobile app to see:

* Your primary and additional campuses.
* Ministries where you participate, volunteer, or lead.
* Community groups you have joined or asked to join.
* Connections that are still waiting for approval.

From this screen, you can request a campus or ministry connection, choose
whether an active connection appears in the Member Directory, or leave a
connection you no longer participate in.

## Open Community and find a group

Community Groups are designed for members and are separate from the permission
groups used to manage dashboard administrators.

To find a group:

1. Open **Community** from **Connect** in the mobile app.
2. Use **My Groups** to return to an active or pending group, or select
   **Discover** to search and filter available groups.
3. Open a group to review its campus, schedule, meeting location, and joining
   policy.
4. Select **Join group**.

Open groups add you immediately. Groups that require approval show a pending
status until a leader or staff member responds. Invite-only groups cannot be
joined without an invitation.

## Collaborate in a group

After joining a group, members can read announcements, participate in the
discussion feed, open shared study guides, and enter any chat channel connected
to the group. Discussion channels let active members converse. Announcement
channels are read-only for ordinary members; group leaders and staff can post.
Group leaders can also publish feed announcements and study guides, record
attendance, and keep leader-only notes.

Chat access follows Community Group membership. A member receives access after
joining or approval, and loses access after leaving or removal. Members keep
using the normal chat experience, including reactions, replies, attachments,
read states, and mute controls.

## Manage connections as staff

From the **Members** area of the web dashboard, staff can:

* Assign campuses, ministries, and community groups to a member.
* Choose a member's primary campus and role in each connection.
* Review pending campus, ministry, and community-group requests.
* Approve or decline requests.
* Create and maintain member-facing community groups.
* Publish group announcements and study guides.
* Review discussion activity, attendance records, and leader-only notes.
* Open **Chat channels** for a Community Group and create its discussion or
  announcement channel.
* Select **Reconcile access** if channel participation ever falls out of sync
  with active group membership.
* Decide whether member campus and ministry requests require approval.

Connections assigned by staff become active immediately.

The **Chat channels** action is available to main administrators and staff with
Community Group management permission. Each group can have one discussion
channel and one announcement channel.

Churches preparing practical-help requests can also use the permission-gated
[Needs & Offers moderation guide](/product/needs-and-offers) to configure safe
audiences, review posts, coordinate follow-up, and resolve reports before the
member board is enabled.

## Use connections in the Member Directory

Members can filter the directory by:

* Campus
* Ministry
* Community group
* General location

Only active connections that a member has chosen to show are used in directory
results. Location filtering uses visible city, state, or country information;
it never exposes a private street address.

## Privacy and safety

* A member controls whether each connection appears in the directory.
* Pending, declined, and inactive connections are not shown in directory
  results.
* Members only see information from their own church.
* Existing directory protections for children and private profile fields still
  apply.
* Separately opted-in Community coordination may suggest a useful connection
  for staff review. It uses member-entered interests and approximate named
  areas, and never silently connects people or exposes a relationship-risk
  score.


# Member Data Hygiene and Migration
Source: https://docs.thefaithapp.com/product/member-data-hygiene

Keep member records accurate, privacy-aware, and ready for directory use.

Member Data Hygiene helps staff clean up directory records and safely move
people from another church-management system.

## Review directory quality

Open **Members → Data hygiene** to review duplicate records, incomplete
profiles, directory consent that needs attention, address values that can be
normalized, and the quality of the latest import.

Duplicate merges keep the selected primary record and archive the other record.
Address cleanup always shows a preview before applying changes.

## Export people from your previous system

Member migration uses a CSV export, so you do not need to connect a provider
account.

* **Planning Center People:** Open People, choose **Actions → Import & export
  CSV**, and start a full-database or list export. [View Planning Center's
  instructions](https://help.planningcenter.com/en/138570-export-data.html).
* **Breeze ChMS:** Export the people and fields you need, save the spreadsheet
  as CSV, and keep the **Breeze ID** column. [View Breeze's
  instructions](https://support.breezechms.com/hc/en-us/articles/360001160713-Exporting-People).
* **Subsplash People:** Export all people or a filtered group and keep the
  `profile_id` column. [View Subsplash's
  instructions](https://support.subsplash.com/en/articles/11178580-advance-filtering-emailing-exporting-people).
* **Tithe.ly People:** Open People, choose the download action, and select CSV.
  [View Tithe.ly's
  instructions](https://help.tithe.ly/hc/en-us/articles/7473258509719-Export-People-Data).
* **Another system:** Choose **Other CSV** and use the sample template in the
  import drawer.

Files can contain up to 10,000 data rows and can be no larger than 10 MB.

## Validate before importing

1. Open **Members** and choose **Import members**.
2. Select the source system, then upload the CSV.
3. Review the suggested column mapping. Map a full name, or a first/last name,
   and at least an email or phone. Map the provider person ID when available.
4. Choose **Validate and preview**. No members are added during this step.
5. Review accepted, duplicate, rejected, and empty rows. Download the review
   CSV if you need to correct any excluded rows.
6. Commit only the accepted rows when the preview looks right.

The preview matches existing records in the same church by provider person ID,
email, or normalized phone. It also detects repeated people inside the file.
Duplicate, rejected, and empty rows remain outside the directory.

In **Import history**, **Accepted (preview)** shows rows that passed validation
before a migration is committed. These preview counts do not mean member
records were added. A completed migration shows its historical **Imported**
count. **Uploaded by** identifies the staff member who supplied the file.

If an attempt reports a failure, check **Import history** and the member
directory before retrying.

> [!NOTE]
>
> Imported members are not invited automatically. Review the new records, then
> use the member invitation action when each person is ready for access.

## Undo and correct an import

Open **Import history** to download the review file or undo a completed
migration. Undo removes only the members added by that migration. Correct the
CSV and upload it again; a fresh preview checks it against the current
directory before any new commit.

## Privacy safeguards

Only staff with Members permission can use migration tools. Uploaded CSVs and
review reports are encrypted while stored, and every migration remains inside
the church that created it. Audit history keeps action names, provider and
field names, and outcome counts without copying member names, contact details,
or raw row values.


# Member Directory
Source: https://docs.thefaithapp.com/product/member-directory

A privacy-first church directory where members find and connect with each other, and staff manage households, approvals, and visibility.

The Member Directory helps people in your church find and connect with one another, while giving every member control over what they share.

## Online, printed and bulk directory needs

Use the member-facing directory for searchable profiles and households in the
mobile app. Check these separate needs before choosing it for a photo-directory
project:

* **Printed photo booklets:** there is no built-in photo-booklet generator or
  choice of print layouts. Plan any printed directory separately, including
  permission to use each person's details and photo.
* **Staff lists:** the web dashboard's [Members Directory](/product/members-directory#export-to-csv)
  exports the current filtered list or selected members as CSV. This is a
  spreadsheet of member records, without photos or a print-ready layout.
* **CSV imports:** **Import Members** adds accepted records from a
  CSV. It skips matching existing records rather than updating them, and does
  not import profile photos. Members can update their own profile photo in the
  app; a folder of photos is not a supported bulk-import format.

A staff CSV export is separate from the member-facing directory and can include
contact and other personal details hidden there. Review what people have agreed
to share, remove unneeded fields, and decide who may receive a copy before
distributing a file or printed list. Later changes to app visibility do not
change copies already downloaded or printed.

## For members

From the mobile app, members can:

* **Browse and search** the church directory by name.
* **Open a member's profile** to see what that person has chosen to share — including their active connections and any contact details, location, birthday, or household they've made visible.
* **View a household** to see the family together.
* **See upcoming birthdays** — a "Birthdays this week" view highlights celebrations among visible members.
* **Use the directory offline** — the last directory list a member loaded is shown even without a connection, with a clear offline indicator until it refreshes.
* **Control their own privacy** from the directory's privacy screen:
  * A master "Show me in the directory" switch.
  * Whole-profile visibility: everyone in the church, leaders only, or hidden.
  * Per-field visibility for email, phone, address, birthday, and household.
* **Update their own profile** from the edit-profile screen:
  * **Set a profile photo** by choosing an image from their library or taking a new one.
  * **See their household** (read-only — households are managed by staff).
  * When the church requires approval for sensitive changes, get a clear **"submitted for approval"** confirmation listing the fields awaiting staff review, while non-sensitive changes save immediately.

Contact details are **private by default**. A field only appears to others once the member (or the church default) makes it visible. The member's privacy controls also live on the profile page, so they're easy to find.

## For staff and admins

From the web dashboard, under **Members**, staff can:

* **Directory Settings** — turn the directory on or off, choose default field visibility, show or hide member photos, and decide whether to include children.
* **Households** — create households and add members by searching for them by name or email (members already in the household are filtered out), and set each member's role, so families appear together.
* **Change Requests** — review and approve or reject sensitive profile edits (name, contact, birth date) when approval is required. This is opt-in per church.
* **Leaders** — designate directory leaders, who can see "leaders only" fields.
* **Birthday & anniversary reminders** — opt in to a daily digest of today's birthdays and anniversaries, pushed to directory leaders.

## Privacy and safety

* Children are excluded from the member-facing directory by default.
* Privacy is enforced for every request — a member only ever receives the fields they're permitted to see.
* Members of one church can never see members of another church.

## Current product notes

* The member-facing directory, household view, and privacy controls live in the mobile app.
* Directory settings, household management, the change-request approval queue, and leader designation live in the web dashboard under Members.
* Campus, ministry, Community Group, and privacy-safe location filters are part
  of [Member Connections](/product/member-connections).


# Member Profiles
Source: https://docs.thefaithapp.com/product/member-profiles

Open one member to see their activity, contact details, household, groups, giving, and care in one place, and keep staff notes and tags on the record.

# Member Profiles

Every member has a profile page that brings together everything the church knows about that person. Use it to prepare for a visit, answer a question about someone's history, or leave a note for the next staff member who opens the record.

## Before You Start

* Sign in to your admin account and open **Church Management**.
* Profiles are opened from the **Members** list, from the search box in the header, or from a link another admin shares with you.
* Notes marked as visible to pastoral staff are only shown to admins whose role includes the **Pastoral Care** permission. See [Pastoral Care](/product/pastoral-care) for how roles are assigned.

## Open a Profile

1. Open **Church Management → Members**.
2. Click any row in the list, or press the view icon at the end of the row.
3. The address bar now holds a link to this member. Copy it to share the profile with another admin.

You can also press **Cmd+K** (Ctrl+K on Windows) anywhere in the dashboard, type the member's name, email, or phone number, and press Enter. See [Search and the Attention Bell](/product/search-and-attention).

## What the Profile Shows

The top of the page shows the member's photo, name, status (Active or Inactive), when they joined, and when they last signed in to the mobile app. Beneath it sit four quick numbers:

| Number | What it means |
| - | - |
| Attendance | Services attended out of services recorded, over the last several weeks. |
| Giving this year | Completed gifts since 1 January in the church's currency. |
| Groups & teams | How many groups and serving teams the member belongs to. |
| Open follow-ups | Follow-ups assigned to staff that are not yet done. |

The buttons in the header let you **Message** the member, **Add note**, **Assign follow-up**, or **Edit** their record.

### Activity timeline

The left column is one timeline of everything that has happened with this member, newest first. It joins:

* visits and visitor follow-ups,
* gifts,
* attendance,
* care cases,
* form responses,
* group and team changes,
* staff notes.

Use the filter chips above the timeline (**All**, **Visits**, **Care**, **Giving**, **Groups**, **Forms**, **Notes**) to narrow it, and **Show older activity** to load more.

### Sidebar

The right column summarises the record:

| Section | What you see |
| - | - |
| Tags | Short labels such as "Hospitality team" or "Baptism interest". |
| Contact | Email, phone, and address. Fields the member has not provided say so. |
| Household | The household this member belongs to, with the other members in it. Households are managed under **Members → Directory → Households**. |
| Groups & serving | Community groups and serving teams, with the member's role. |
| Giving | This year's total, the last gift, the funds given to, and a link to statements. |
| Follow-ups | Open follow-ups assigned to staff, with due date and owner. |
| Care | Open care cases with their next follow-up date and owner. Confidential cases show only that a confidential case exists. |

## Add a Note

Notes are for things the church should remember about a person: a conversation after a service, a prayer request, a pastoral concern.

1. Open the member's profile and click **Add note**, or scroll to the note box at the top of the timeline.
2. Type the note.
3. Choose who can read it:
   * **Visible to all staff** — any admin who opens the profile.
   * **Visible to pastoral staff** — only admins whose role includes the Pastoral Care permission. This choice is offered only if your own role includes it.
4. Click **Save note**.

The note appears in the timeline with your name and the time. Anyone who can read a note can delete it with **Delete note**. Pastoral notes are invisible to staff without the Pastoral Care permission: they do not appear in the list or the timeline, and cannot be deleted by them. Notes are stored encrypted.

## Assign a Follow-up

A follow-up is something a staff member owes this person: a call after a hospital stay, a text about the baptism class, a visit.

1. Click **Assign follow-up** in the profile header.
2. Describe what needs to happen, and add details if the owner needs context.
3. Choose how (phone call, text message, email, in person), who owns it, and when it is due. The owner defaults to you.
4. Click **Assign**.

**How** starts with **Phone call** when a number is recorded, **Email** when
only email is recorded, or **No channel** when neither is available. If you
choose phone, text, or email without the matching contact detail, a hint
explains what is missing. You can still assign the task, or choose **In person**
or **No channel**. Assigning a follow-up records a task; it does not send a
message or place a call.

Open follow-ups are listed in the **Follow-ups** section of the sidebar with their due date, owner, and an overdue marker, and the header shows an **Open follow-ups** count. When it is done, click **Mark done**, write what happened, and confirm. The follow-up moves into the timeline as "Follow-up completed".

Member follow-ups also appear on the dashboard under **Follow-ups due today** and count toward the overdue follow-ups line in the attention bell. See [Dashboard and Internal Tools](/product/dashboard-and-internal-tools).

## Add or Remove Tags

Tags are quick labels that group people across the church. They also power the tag filter in the [Members directory](/product/members-directory).

1. In the **Tags** section of the sidebar, click **Add tag**.
2. Type the tag and press Enter. Tags are matched regardless of capitalisation, so "hospitality" and "Hospitality" are the same tag.
3. To remove a tag, click the × on it.

A member can carry up to 20 tags, and each tag can be up to 40 characters.

## Notes

* Edits to the member's own details (name, contact, birth date) still open the existing edit drawer. If your church requires approval for sensitive changes, edits made by the member in the mobile app appear as change requests under **Members → Directory → Change Requests**.
* The giving summary counts completed gifts only. Pledges are shown separately where they exist.
* Profiles only show members of your own church.


# Members Directory
Source: https://docs.thefaithapp.com/product/members-directory

Work the Members list like a directory with saved views, filters for groups, tags, sign-in, and giving, a column chooser, CSV export, and bulk tagging.

# Members Directory

The **Members** page is where staff find people, build lists, and act on them. This guide covers the admin list in the web dashboard. The member-facing directory in the mobile app, household management, and privacy settings are covered in [Member Directory](/product/member-directory).

## Before You Start

* Sign in to your admin account and open **Church Management → Members**.
* The summary tiles at the top (Total, Active, Inactive, New this month) are clickable. Each one switches the list to the matching view.
* Saved views and your column choice are remembered on the browser you are using, not on your account.

## Choose a View

Views are ready-made lists across the top of the page:

| View | Who is in it |
| - | - |
| All members | Everyone in your church. |
| Active / Inactive | Members by status. |
| New this month | Members added since the first of the month. |
| Not in a group | Members who belong to no community group. |
| Never logged in | Members who have never signed in to the mobile app. |
| Lapsed givers | Members who gave last year but have not given this year. |

Click a view to apply it. The filters and search box still work on top of a view, so you can narrow "Never logged in" to one gender or one group.

## Add One Member

Open **Members → Add New Member** to save a name without preparing a CSV.
Email and other profile details are optional when you only want to save a
record. Saving a record does not send an invitation.

Choose **Send a welcome invitation now** only when the person is ready to
receive sign-in details. An email address is required for this option. To
invite them later, add their email through the member's edit action, then
choose **Send welcome invitation** in the directory. After an invitation has
been sent, the action changes to **Resend invitation** until they sign in.

Adding a record and sending an invitation require Members permission. Your
plan's member limit applies to records whether or not you send an invitation.

If saving fails, the drawer keeps your details and shows the error so you can
correct it and try again. After success, the directory and counts refresh.

When your directory is empty, you can choose **Add New Member** for one person
or **Import Members** for a CSV. If a search has no matches, **Clear filters**
clears the search and filters to show all members again.

## Filter and Sort

The filter row sits under the views:

* **Search** by name, email, or phone.
* **Gender** and **Status**.
* **Group** — a specific community group, or **Not in a group**.
* **Tag** — any tag you have added on member profiles.
* **Giving** — **Gave this year** or **Lapsed givers**.
* **Joined since** — a date.

Each active filter appears as a chip under the filter row. Click the × on a chip to remove that one filter, or **Clear filters** to return to **All members** with no filters. Click a column heading to sort by name, groups, or last login.

## Save Your Own View

1. Set the filters you want.
2. Click **Save view**, type a name such as "Youth parents with no group", and confirm.
3. The view appears alongside the ready-made ones. Click the × on it to remove it.

## Choose Columns

Click **Columns** to show or hide phone, gender, location, tags, groups, status, and last login. The member's name is always shown. Your choice stays until you change it on this browser.

## Export to CSV

**Export** downloads the members in the current view and filters as a CSV file you can open in Excel or Google Sheets. It includes name, email, phone, gender, age group, location, status, tags, number of groups, last login, and the date the member joined.

To export only some people, tick them first and use **Export selected** in the bulk bar.

## Work With Several Members at Once

Tick the boxes beside the members you want, or the box in the header to select the whole page. A bulk bar appears with:

| Action | What it does |
| - | - |
| Add tag | Type a tag and press **Add tag** to put it on everyone selected. |
| Add to group | Choose a community group and press **Add to group**. Everyone selected joins as an active member. People already in the group are skipped, and if the group has a capacity and fills up, the confirmation says how many were not added. |
| Message | Opens Communications with these members as recipients. |
| Export selected | Downloads just these rows as a CSV. |
| Clear selection | Unticks everyone. |

## Open a Member

On phones, members appear as cards with a readable name, contact details,
selected directory fields, and labeled actions. Select the name or **View** to
open the profile. Use **Manage member connections** to review connections, or
the invitation action when one is available. Selection boxes and sorting
controls remain available above and beside the cards.

On larger screens, click a row to open the member's profile, where you can read their full history, add notes, and manage tags. See [Member Profiles](/product/member-profiles).

## Notes

* **Import members** and **Import history** are still in the page header for bulk uploads.
* A member with an unsent or expired invitation still shows the **Resend invite** action on the row.
* Tags added in bulk are the same tags that appear on each member's profile and in the tag filter.
* Because saved views live on the browser, a colleague will not see the views you saved. Share the filter settings instead.


# Use and moderate Needs & Offers
Source: https://docs.thefaithapp.com/product/needs-and-offers

Share practical needs and offers safely in the mobile app, then review and coordinate them from the web dashboard.

Needs & Offers gives adult members a moderated place to request or offer
practical help without publishing personal contact details. The board is
disabled by default so staff can review its safeguards before members begin
using it.

## Find the member board

In the mobile app, open **Connect**, select **Community**, then choose
**Needs & Offers**. This option appears only after the church enables the board
and the signed-in member is eligible to use it.

Use the top filters to switch between needs and offers or narrow the board by
category, campus, Community Group, audience, or status. Each card shows only a
safe summary, approximate audience, published age, and expiry information.

![Needs & Offers member board](https://mintcdn.com/thefaithltd/tTm_Yythw-nFF76-/images/product/needs-and-offers/member-board.png?fit=max\&auto=format\&n=tTm_Yythw-nFF76-\&q=85\&s=f00d090c875788990e8c4f87cbdb3f07)

## Publish a need or offer

Select **Post**, choose whether you need help or can offer it, and complete the
short form. You can choose an allowed audience, such as your campus, Community
Group, or leaders only.

Keep phone numbers, email addresses, exact street addresses, and other direct
contact details out of the title and description. Responses begin privately in
the app. Depending on church settings and category, a post may appear
immediately or be sent to staff for review.

### Donation drives

Choose **Donation drive** when the church is collecting items or funds for a
shared response. Staff review the post and connect it to an active Outreach
Campaign before publishing it.

Once connected, the post shows **View campaign & contribute**. This opens the
church's existing campaign page with the current requested items, payment
options, delivery details, and progress. Members do not need to choose between
two different donation forms.

### Employment help

Choose **Employment information** for a job opening, a request for work,
career mentoring, or résumé and interview help. The form also records whether
the help is on-site, remote, or hybrid and whether it is one-time, short-term,
or ongoing.

Employment posts use the same reviewed Needs & Offers workflow. The app does
not score or automatically match members, and contact details remain outside
the public post. The saved help type, work mode, and time commitment remain
visible on the member post and in the staff review drawer.

### Future community pilots

When your church opens relational research, the mobile **Community** screen
shows **Help shape future community support**. Open it to privately select
future ideas you may consider, such as skills sharing, recurring rides,
intergenerational connections, nearby practical help, or newcomer connections.

This records research interest only. It does not create a match,
recommendation, chat, or relationship-risk score. Your church sees only
combined counts, and small counts are hidden. You can update your choices or
withdraw at any time, including after the church pauses new interest.

## Borrow or lend a community resource

When your church enables **Community resources**, open **Community** and select
the resource card. Use **Browse** to find reviewed lending items and
staff-coordinated medical equipment. Select **Request item** and add an optional
private note without contact details.

Use **My items** to lend an item you own. Staff review every listing before it
appears. You can approve or decline a request, mark an approved loan checked
out, and record its return. **My loans** shows your requests, due dates,
overdue state, cancellations, and returns.

Medical equipment is always reviewed and coordinated by staff. Members never
see its exact storage location, and only staff approve, check out, or return a
medical-equipment loan. A borrower sees staff-coordination guidance instead of
a return action.

## Respond and coordinate privately

Open a post and select **Respond privately**. The response is visible to the
post author and authorized staff, not to the public board.

The author can accept or decline responses. Once a response is accepted, both
members can continue in a private in-app conversation. The author can then mark
the post fulfilled or close it for another reason.

Open **My activity** to review your posts and responses. From there you can
edit or extend an eligible post, mark it fulfilled, close it, withdraw a
response, or return to an accepted private conversation.

Use **Report** on a post when staff should review a safety or conduct concern.
Needs & Offers is not an emergency service; contact local emergency services
or a trusted church leader when immediate help is needed.

## Set up the board

Open **Members**, select **Needs & Offers**, then open **Settings**.

Before enabling the board, review:

* Whether every post must be approved before publishing.
* Whether church-wide posts are allowed or audiences stay limited to a campus,
  Community Group, or leaders.
* Whether an author may choose to show their name.
* Which categories are enabled.
* Which categories always require review.
* Default and maximum expiry periods for each category.
* Whether the separate research-interest registry is open to eligible adult
  members.
* Whether the reviewed Community resource library is available to eligible
  adult members.

The safest launch settings are already selected: the board is off, every post
requires review, church-wide visibility is off, and author names are hidden.
Sensitive categories remain leaders-only and always require review.

After staff confirm those safeguards, this is also the screen where they can
enable or pause the member board.

![Needs & Offers safeguards](https://mintcdn.com/thefaithltd/tTm_Yythw-nFF76-/images/product/needs-and-offers/staff-safeguards.png?fit=max\&auto=format\&n=tTm_Yythw-nFF76-\&q=85\&s=35bf16bcd7d9316508b16101ebb7b0d7)

## Review relational research readiness

Open **Research pilots** to see voluntary interest before designing any future
pilot. This page never lists participating members. It shows combined counts
only and displays **fewer than 5** when a church or research area has fewer than five
active opt-ins.

The page also keeps the research boundaries visible: no automatic matching,
no member identities, no precise location, no relationship-risk scores, adult
participation only, and withdrawal at any time. Interest is discovery input,
not approval to launch a matcher. Complete pastoral, safeguarding, fairness,
and explainability review before proposing a pilot.

## Review a post

Staff with Needs & Offers view permission can open the moderation queue and
review a post's requested audience, safe location, author context, responses,
reports, and audit history.

Staff with moderation permission can:

* Approve and publish a pending post.
* Ask the author for a safer edit without rewriting their words.
* Restrict a post to leaders only.
* Assign a staff coordinator.
* Reject or close a post with a recorded reason.

For a donation drive, staff who also have Outreach Campaign access select an
active campaign in the **Donation coordination** section. The post cannot be
approved until a campaign that accepts items or cash is linked. Use **Manage
campaign** to update requested items, payment options, delivery instructions,
and pledge progress in the existing Outreach Campaign workflow.

## Coordinate an assigned post

A staff member assigned to a post gets an **Assigned Needs & Offers** entry
even when they do not have the board-wide view or moderation
permissions. It shows only the assigned post and its private responses. The
coordinator can accept or decline a response, mark the post fulfilled, or close
it with a reason.

Assignment does not open the moderation queue, reports, audit history,
settings, staff directory, or any other post. Reassigning the post removes the
previous coordinator's access immediately.

Time-sensitive and sensitive-category posts show a pastoral review warning.
Needs & Offers is not an emergency service; use your church's existing
safeguarding and emergency procedures when urgent follow-up is required.

## Handle reports

Open **Reports** to review member safety concerns. Reporter identity is visible
only inside the permission-gated staff queue and is never shown to a post
author or other members.

Three reports from different members within 24 hours pause an open post for
review by default. Staff can resolve or dismiss a report with an optional note.

## Manage resources and ministry chats

Open **Resources** in Needs & Offers to review member lending items, add
church-managed medical equipment, approve or restrict listings, and coordinate
loan approval, checkout, overdue, and return states. Resource access reuses the
Needs & Offers view and moderation permissions.

Open **Volunteers → Ministries** and select the chat action for a ministry to
create one private discussion and one leader-posting announcement channel.
Active ministry membership controls chat access, ministry leaders become chat
moderators, and **Sync membership** reconciles any drift.

## Choose communication preferences

From the mobile Notifications screen, open **Communication preferences**.
Members can schedule recurring quiet hours by local time and weekday. The app
automatically starts with the church's time zone, and a dropdown of valid time
zones is available when it needs to be changed. Members can then enable or
pause push notifications for direct messages, ministries, Community Groups,
and Needs & Offers.

Inside an individual chat, choose **All messages**, **Mentions only**, or
**None**. The server applies quiet hours, topics, and the channel choice before
sending push notifications. Messages and in-app activity remain available.

## Automatic expiry and private contact

Posts expire automatically according to their category. The author receives a
generic in-app update that does not repeat the post title, description,
location, or other sensitive details.

Phone numbers, email addresses, and exact street addresses are rejected from
post content. The offline mobile board stores only safe card summaries and does
not store post descriptions, author details, response notes, or contact data.
Responses begin privately inside the app.

## Staff permissions

Needs & Offers uses three separate permissions:

* **View Needs & Offers** reads the moderation and reports queues.
* **Moderate Needs & Offers** approves, restricts, assigns, rejects, closes,
  and resolves reports. A moderator also needs view permission.
* **Configure Needs & Offers** changes the board's church-level settings,
  controls whether research interest is open, and reads thresholded research
  readiness. It does not expose participant identities.

Being assigned as a coordinator is post-specific access, not a fourth broad
permission. It provides only the assigned coordination actions described
above.

Main administrators receive all three permissions automatically.

Linking or changing a donation drive's campaign additionally requires the
existing **Outreach Campaigns** permission. Assigned coordinators can see the
linked campaign summary but cannot change it unless they also have the full
view, moderation, and Outreach Campaign permissions.

Report access follows the existing **View Needs & Offers** permission; a second
recipient-role system is not created. Community Group chat provisioning also
stays in the existing **Chat channels** action for each group.

## Launch or pause the board

Use a small canary group of churches before enabling Needs & Offers broadly.
For each church, leave the board disabled while staff confirm permissions,
categories, review rules, audience choices, expiry periods, and safeguarding
ownership. Then enable it from **Members → Needs & Offers → Settings**.

Monitor the moderation queue, report rate, time to first response, expired
posts, and private-chat handoffs during the canary. These measures are for
workflow health and must not become public member rankings or generosity
scores.

To pause a church immediately, turn the board off in the same Settings screen.
Members will no longer see the board or be able to read or change posts. The
existing posts, reports, decisions, and audit history remain available for a
safe investigation and later re-enable; do not delete them as part of a pause.

The research-interest registry has its own setting. Leave it off until a named
pastoral owner approves the research notice. Turning it off pauses new and
updated interest while keeping withdrawal available to anyone who previously
opted in.


# New Visitor Journey
Source: https://docs.thefaithapp.com/product/new-visitor-journey

Set up a welcoming guest page, collect Connect Cards, and coordinate thoughtful follow-up from one Visitor Inbox.

The New Visitor Journey gives first-time guests a simple way to learn what to
expect, plan a visit, or ask for help. Guests can use the public pages without
creating an account or signing in.

When a guest submits a form, the response appears in **Visitor Inbox** so your
team can assign an owner, follow up, and keep the full story in one place.

## Before You Start

Make sure you have:

* Access to **Branches** and **Visitor Inbox**.
* At least one branch with its address and active gathering times added.
* Arrival, parking, kids, accessibility, and welcome-desk information for each
  branch.
* A public welcome image address if you want to show a custom photo.
* A church-owned Handwrytten account if your team wants to send physical
  welcome cards.

> [!TIP]
>
> Read the public page as if you were arriving at your church for the first
> time. Details that feel obvious to regular members can be very helpful to a
> new guest.

## 1. Prepare Each Branch

The public guest pages use the information saved on the selected branch.

![Visit information in the branch editor](https://mintcdn.com/thefaithltd/14k7s2zNSjWvVYcb/images/product/new-visitor-journey/branch-visit-information.jpg?fit=max\&auto=format\&n=14k7s2zNSjWvVYcb\&q=85\&s=3ca32a99bf177a61556703024aa30367)

### Steps

1. Open **Branches**.
2. Find the branch you want to update and select its edit button.
3. Scroll to **Visit Information**.
4. Add clear arrival, parking, kids, accessibility, welcome-desk, public
   contact, and map information.
5. Paste a public **Welcome image URL** if you want to show a custom photo.
6. Choose a **Page theme color** that works with your church branding.
7. Select **Update Branch**.

### Welcome Image Tips

* Use a bright, welcoming photo of the church, entrance, or community.
* The image must already be online and have a public address beginning with
  `https://`.
* If you do not manage your church website, ask the person who does to give you
  the image address.
* Do not use a private photo link that requires someone to sign in.

> [!WARNING]
>
> Do not place private staff details or sensitive pastoral information on the
> public page. Only add contact information that the church is comfortable
> sharing publicly.

## 2. Preview the Guest Experience

Use the public page to check exactly what a guest will see before you share it.

![Public Plan a Visit page](https://mintcdn.com/thefaithltd/14k7s2zNSjWvVYcb/images/product/new-visitor-journey/public-plan-a-visit.jpg?fit=max\&auto=format\&n=14k7s2zNSjWvVYcb\&q=85\&s=2bb295ddc5c886e60a0c2bb38273ef7e)

Check that:

* The church name, photo, and theme color look correct.
* The address, arrival, parking, kids, and accessibility details are easy to
  understand.
* The correct branches and gathering times appear.
* The form works well on both a phone and a computer.
* The contact-permission choices are clear.

Guests do not need an account. They can complete the form directly from the
public page, even though a **Sign In** option may also appear in the header.

## 3. Share or Embed the Pages

Open **Visitor Inbox** and select **Generate visitor links**.

![Visitor page links and embed code](https://mintcdn.com/thefaithltd/14k7s2zNSjWvVYcb/images/product/new-visitor-journey/visitor-page-links.jpg?fit=max\&auto=format\&n=14k7s2zNSjWvVYcb\&q=85\&s=df8bc2cd36af1b468f56b4ad4d2f988c)

You will see two guest pages:

* **Plan a Visit** helps someone prepare for a service and choose a branch,
  gathering, and planned visit date.
* **Connect Card** lets someone ask a question, request support, show interest
  in a next step, or request a pastor conversation.

### Share a Direct Link

1. Select the copy button beside the page you want to share.
2. Paste the link into an email, message, social profile, QR code, or website
   button.
3. Open the link yourself once to confirm that it works.

### Place a Form on Your Website

1. Copy the **Embed code** for the page you want.
2. Paste it into the part of your website that accepts custom HTML or embed
   code.
3. Open the website on a phone and computer to check the size and spacing.

> [!TIP]
>
> If you do not manage the website, send the complete embed code to the person
> who does. They should paste it as supplied rather than changing the link
> inside it.

## 4. Understand the Connect Card

The Connect Card is designed to feel welcoming and optional. Only a name and
one way to reach the guest are required.

![Public Connect Card](https://mintcdn.com/thefaithltd/14k7s2zNSjWvVYcb/images/product/new-visitor-journey/public-connect-card.jpg?fit=max\&auto=format\&n=14k7s2zNSjWvVYcb\&q=85\&s=36b6e7366467c67d7f925b4ed96cbbb3)

A guest can:

* Select an area of interest.
* Add a question or message.
* Choose a preferred contact method.
* Allow email, text, or phone contact separately.
* Ask for a pastor conversation.
* Choose **No follow-up** when they do not want to be contacted.

Asking for a pastor conversation does not automatically give permission for
marketing messages.

## 5. Work From Visitor Inbox

Every submitted Plan a Visit form or Connect Card appears in **Visitor Inbox**.

![Visitor Inbox](https://mintcdn.com/thefaithltd/14k7s2zNSjWvVYcb/images/product/new-visitor-journey/visitor-inbox.jpg?fit=max\&auto=format\&n=14k7s2zNSjWvVYcb\&q=85\&s=566152619e7e8225a270612fb876b8d0)

Use the search box and filters to find someone by:

* Name, email address, or phone number.
* Journey status.
* Branch, follow-up owner, or form source.
* Submission date.
* Pastor-call request.
* Overdue follow-up.

The cards at the top give your team a quick view of new visitors, planned
visits, completed visits, pastor-call requests, and overdue work.

### Helpful Terms

* **Status** shows where the guest is in the journey, such as new, visit
  planned, visited, or following up.
* **Owner** is the staff member responsible for the next personal response.
* **Overdue** means a staff follow-up task has passed its due date and is not
  complete.

## 6. Follow Up With One Visitor

Select a visitor row to open their details.

The visitor drawer is organized into four tabs:

* **Overview** shows contact details, journey status, follow-up ownership,
  recommended next steps, visit plans, and contact permission.
* **Follow-up** contains staff tasks and private notes.
* **Handwrytten** contains the church's welcome-card workflow and order history.
* **Timeline** shows the complete chronological visitor journey.

Before contacting someone, check both their preferred method and the permission
for that exact channel. Permission to email does not also give permission to
text or call.

### Give One Response a Clear Next Action

At the top of a visitor’s **Overview**, choose **Add a follow-up task**. If there is already open work, choose
**Review follow-up tasks** instead so you can check it before creating more.

1. Review the preferred contact method and the permission recorded for each
   channel. **No permission recorded** is not permission to make contact.
2. Select **Add a follow-up task** to open the existing task form in
   **Follow-up**.
3. Choose the task type and staff owner, describe one useful next action, and
   review its due date and time.
4. Select **Create task**. Confirm the saved task shows the intended owner and
   due time.
5. The responsible person carries out the agreed action through a permitted
   channel, then records the actual outcome before marking the task complete.

Creating or assigning a task is an internal reminder. It does not send a
message or confirm that the guest has been contacted. Respect **No follow-up**
choices; the Overview shortcut is not offered for those visitors or for closed
or converted journeys. Staff can still review the existing **Follow-up** tab.

## 7. Configure the Follow-Up Sequence

Select **Follow-up settings** in **Visitor Inbox** to decide what should happen
after a new form arrives.

![Visitor follow-up sequence settings](https://mintcdn.com/thefaithltd/14k7s2zNSjWvVYcb/images/product/new-visitor-journey/follow-up-settings.jpg?fit=max\&auto=format\&n=14k7s2zNSjWvVYcb\&q=85\&s=70edb993b1ea5eba20379f93b905036b)

You can configure:

* A default follow-up owner.
* A personal welcome task and its due time.
* Overdue reminders.
* An immediate pastor-call task when requested.
* Confirmation email and text wording.
* An optional invitation to an upcoming newcomer event.

Select **Save sequence** after making changes.

Automated email and text messages are only sent when that delivery service is
configured and the guest allowed that exact contact channel. Permission is
checked again when the message is about to be sent.

> [!NOTE]
>
> Automation helps the team remember the next action. Personal and pastoral
> follow-up still belongs to the assigned staff member.

## 8. Send a Handwrytten Welcome Card

Churches with their own Handwrytten account can prepare and track a physical
card from the visitor details. Handwrytten bills the connected church account;
TheFaithApp never stores the payment card number.

### Connect the Church Account

1. Open **Settings**, then **Integrations**.
2. Select the **Handwrytten** card to open its setup drawer.
3. Copy an API key from the church's Handwrytten Integrations page.
4. Paste the key into TheFaithApp and select **Connect and test**.
5. Confirm the account mode and default return address shown in TheFaithApp.
6. If the account has no default return address, either choose one of its
   existing saved addresses or enter a new one.
7. Read and select the confirmation checkbox before making that address the
   account default.

Test mode does not print or mail the card, although Handwrytten may place a
temporary payment authorization. Live mode charges the church's Handwrytten
account and sends the physical card.

TheFaithApp does not silently change a Handwrytten return address. Choosing a
saved address or entering a new one requires an explicit confirmation because
the action updates the connected Handwrytten account and can affect other
services that use it. A newly entered address is added to Handwrytten and made
the account default.

### Prepare and Approve a Card

1. Open the visitor in **Visitor Inbox**.
2. Open the **Handwrytten** tab and select **Send a card**.
3. Confirm the visitor's postal address and record how they gave permission to
   receive physical mail.
4. Choose a card design and handwriting style from the connected Handwrytten
   account.
5. Review the message, closing, and read-only Handwrytten return address.
6. Review the completed card before selecting **Submit test card** or the live
   mailing action.

The saved design, message, and handwriting style can be reused as the church's
visitor-card defaults. The return address always comes from the connected
Handwrytten account.

> [!WARNING]
>
> Never send a physical card without the visitor's current permission. In live
> mode, check the recipient, address, message, and charge warning carefully
> before approving the order.

### Track the Result

The visitor details show each draft or order with its test/live state, current
status, message preview, and any provider error. Submitted orders can be
refreshed, and cancellation appears only when the order can still be canceled.

If Handwrytten definitely rejects an order, correct the account or card details
and create a new draft. If the result says it needs review, do not submit it
again until the Handwrytten order history has been checked.

## 9. Link a Visitor to the Member Directory

When the relationship is ready, open the visitor and select **Link existing
member** or **Convert to member**.

The app shows possible records with the exact same email address or phone
number so staff can review them first. It never merges those records
automatically.

The original visit, notes, tasks, and timeline stay in Visitor Inbox. Contact
permission is not copied to the member record, and converting a visitor does
not send account credentials.

## Recommended Next Steps

The guest confirmation page and visitor details only show actions that are
available for that church and person. After a visitor is linked to a member,
the member Home screen can also recommend useful actions such as:

* Choose a branch.
* Join an active Community Group.
* Explore an upcoming event.
* Find an active serving opportunity.
* Request prayer.
* Continue a requested pastor conversation.

Published Bible plans, membership pathways, and baptism pathways can appear as
member recommendations and open the relevant formation experience. A church
must publish the matching pathway before that recommendation is shown.

## Before You Share the Pages

* Preview both **Plan a Visit** and **Connect Card**.
* Test the pages on a phone and computer.
* Confirm every branch has current public information and gathering times.
* Submit one test response and confirm it appears in **Visitor Inbox**.
* Confirm the correct staff member receives ownership.
* Review the confirmation wording and contact permission.
* Close the test visitor and complete its test tasks when testing is finished.

## Common Questions

### Does a guest need to create an account?

No. The Plan a Visit and Connect Card forms work without sign-in.

### Does submitting a form create a member record?

No. It creates a visitor record. Staff choose later whether to link or convert
the visitor to a member.

### Can both forms be placed on our church website?

Yes. Use the embed code shown under **Generate visitor links**, or share the
direct links from buttons on your website.

### What happens if two records have the same email address or phone number?

The app shows a possible match for staff to review. It does not automatically
merge or delete either record.

### Can the system send a message without permission?

Automated messages only use a channel the guest specifically allowed. Staff
should also review and respect the guest's choices before making personal
contact.

## Current Product Notes

* Newcomer invitations can use an upcoming Event or a published membership
  pathway. Baptism recommendations use a published baptism pathway.
* Physical card artwork is created and managed in Handwrytten. TheFaithApp
  provides selection, approval, submission, and visitor-history tracking.
* Handwrytten test mode still requires a payment method that can accept a
  temporary authorization, even though the card is not mailed or charged.


# Operations and Facilities
Source: https://docs.thefaithapp.com/product/operations-and-facilities

Coordinate rooms, resources, Sunday execution, safety, access, transport, and emergency readiness.

Operations & Facilities gives church teams one place to prepare the building,
run services, resolve issues, and coordinate a safe response. Members can make
eligible requests in the mobile app, while staff use permission-controlled
sections in the web dashboard.

> [!WARNING]
>
> TheFaithApp records church coordination. It does not replace trained safety
> leaders, local emergency services, safeguarding policy, building inspection,
> driver licensing, insurance, or legal compliance.

## Before You Start

1. Name the people responsible for facilities, service operations, safety, and
   restricted access.
2. Give each person only the Operations viewing, management, safety, or
   sensitive access their role needs.
3. Confirm your emergency contact tree, assembly areas, evacuation steps, and
   local emergency procedures outside the app.
4. Gather the current room capacities, equipment quantities, key holders,
   inspection dates, approved drivers, and contractor requirements.
5. Create one test service and rehearse a booking conflict, checklist, alert,
   runbook, incident, weather decision, and role call before rollout.

## Add Rooms, Equipment, and Supplies

Open `Operations & Facilities > Resources & stock`, then add each room,
equipment pool, serialized asset, vehicle, building system, safety item, or
consumable.

Record the location, capacity or quantity, booking and approval rules, stock
and reorder point, asset tag, and next lifecycle or inspection date. Use
serialized tracking for a key, credential, vehicle, or item that can have only
one current holder.

Low stock and overdue lifecycle items appear on the Overview. These are review
signals; the app does not silently revoke access or certify an inspection.

## Review Facility and Equipment Requests

The Calendar shows pending and approved reservations. A room or serialized
item cannot have overlapping approved bookings, while pooled equipment checks
the remaining quantity.

Members can use the mobile **Operations & Facilities** hub to request an
available room or resource, add setup notes, and record climate or lighting
intent. They can also send maintenance, setup, cleaning, access, stock, or
lost-and-found requests and follow the status of their own request.

Approve or decline a booking only after reviewing its time, occupancy,
resource warning, and setup needs. Restricted access detail belongs in the
sensitive workflow rather than an ordinary alert.

When reserving a room or equipment specifically for a service, select its
related service operations plan. The reservation then participates in that
service's readiness checks before publication.

## Prepare Sunday Operations

Open `Services & checklists` and create the service operations plan. Link the
existing Volunteer service plan when one exists, then add:

* The timed run sheet and owners
* Usher, greeter, parking, production, and safety stations
* Parking map reference and zones
* Required rooms or equipment
* Communion portions, cups, dietary alternatives, and reset work
* Baptism count, warm-baptistry confirmation, and towels

Add production, opening, cleaning, setup, sacrament, inspection, or closing
checklists and assign the work. Publication remains blocked while required
resources, volunteer coverage, or lyric-projection permission needs review.

## Publish QR Runbooks and Reconcile CCLI Use

Use `Runbooks & CCLI` to publish a public-safe procedure for equipment or a
building system. Include clear steps and a visible instruction for when to
stop and contact a trained person. Place the generated QR link only where the
procedure is intended to be used.

The public page never displays restricted staff notes, contact trees, key
holders, or operator identity. Rotate the link if it is shared more widely
than intended.

For critical systems, record at least two trained operators where possible.
Review lyric-projection permission before publishing a service, then generate
the date-bounded CCLI usage reconciliation when needed.

## Coordinate Safety and Weather Decisions

Use `Safety & emergency` to publish each emergency plan with its contact tree,
assigned roles, evacuation checklist, assembly guidance, and next drill date.

Service alerts use public-safe instructions and allow acknowledgement and
resolution. Incident reports may contain protected detail and require the
appropriate safety or sensitive access. For immediate danger, follow local
emergency procedures before recording the incident.

A weather decision records the named criteria, observed conditions, decision,
affected church audiences, and explicitly confirmed outside contacts. Review
the scope before cascading it; a sent decision cannot silently expand to a
new audience.

Assigned safety coordinators can start volunteer role call from the mobile
hub. A role call cannot close until everyone in its scope is accounted for.
Children remain in the protected Children & Youth emergency roster.

## Manage Access, Vehicles, and Vendors

The sensitive `Access & transport` section records one current holder for a
key or serialized asset, its due date, and its return. The offboarding view
helps locate open custody and critical-system knowledge before a volunteer
leaves.

Review a driver's licence, insurance, training expiry, and approved vehicle
class before approving a trip. A trip also checks vehicle capacity and time
conflicts. Passenger manifests are protected and should contain only the
information needed for that trip.

Vendor visits record the sponsor, purpose, access window, insurance or
compliance expiry, issued credential label, check-in, and check-out. Record an
asset return or vendor departure promptly so the current access view remains
accurate.


# Outreach and Donor Management
Source: https://docs.thefaithapp.com/product/outreach-and-donor-management

Create outreach campaigns, review campaign donations, manage donors, work with donor forms, and share public campaign pages in TheFaithApp.

# Outreach and Donor Management

This guide covers the outreach tools used to run giving campaigns, manage donor information, and share campaign pages with supporters.

These tools include:

* Outreach campaigns
* Campaign items
* Campaign donations
* Donor directory
* Donor details
* Donor forms
* Campaign analytics
* Public campaign pages

## Before You Start

* Sign in to your admin account.
* Open `Outreach Campaigns` from the six-product sidebar, then choose the campaign, analytics, donations, or donor-management page you need.
* Use the `Campaigns`, `Analytics`, `Donations`, and `Donor Management` sections to move between workflows.
* Before sharing a public campaign, make sure the campaign is active and ready for donors to see.

## Outreach Campaigns

Outreach Campaigns also coordinate donation-drive posts from **Members → Needs
& Offers**. A moderator with Outreach Campaign access can link an active
campaign before publishing the post. Members then open this same campaign for
requested items, contributions, delivery details, and progress rather than
using a separate donation workflow.

Use the campaigns page to create, review, and organize all outreach campaigns in one place.

![Outreach campaigns screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/outreach-donor-management/outreach-campaigns.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=da3be2af61c8ea4c0b74dea641ce275f)

### What You Can Do

* Create a campaign
* Search campaigns
* Filter campaigns by status
* Open a campaign for more detail
* Generate a public link
* Edit or delete a campaign

### Steps

1. Open `Outreach Campaigns`.
2. Stay on `Campaigns`.
3. Use search or the status filter to find the campaign you want.
4. Click `Create Campaign` to add a new campaign, or open an existing one to manage it.
5. Use the page actions when you need to update or share the campaign.

### Notes

* Campaign cards help your team compare progress quickly.
* Active campaigns are the best choice for public sharing.

## Public Campaign Links

Use the public link tool when you want to share a church-wide outreach page outside the admin dashboard.

![Public campaigns link modal](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/outreach-donor-management/campaign-public-link-modal.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=f1db4cd067fbffe4c1f0a43f043b9de4)

### What You Can Do

* Copy the public campaigns link
* Copy embed code for a website or landing page
* Share one outreach destination with supporters

### Steps

1. Open `Outreach Campaigns`.
2. On the `Campaigns` page, click `Generate Public Link`.
3. Copy the direct link or the embed code.
4. Share it with your website manager, church team, or donors.

### Notes

* The public link opens the church's campaign page outside the admin dashboard.
* Use embed code when you want campaigns displayed inside another website.

## Campaign Items and Setup

Use the campaign details page to review the setup of an individual campaign and monitor what supporters still need to give.

![Campaign items and setup](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/outreach-donor-management/campaign-items.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=a7c8fd5bd66a4eb93b14b97e5954185a)

### What You Can Do

* Review the campaign description
* Confirm whether the campaign accepts cash, items, or both
* Track item goals and current progress
* Review donor and donation totals
* Check delivery instructions
* Open editing when updates are needed

### Steps

1. Open `Outreach Campaigns`.
2. Select the campaign you want to review.
3. Check the description, dates, and donation types.
4. Review the campaign items and progress bar.
5. Review the statistics and delivery information.
6. Click `Edit` when the campaign needs changes.

### Notes

* Item progress helps your team see what is still needed.
* Delivery information is useful when supporters are bringing physical items in person.

## Campaign Donations

Use the donations page to review pledged and received support across all outreach campaigns.

![Campaign donations screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/outreach-donor-management/campaign-donations.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=1a6405c4c30da9e9549015426e47767f)

### What You Can Do

* Review giving totals across campaigns
* Search donations
* Filter by status
* Filter by type
* Review campaign, amount, and date details
* Remove a donation record when needed

### Steps

1. Open `Outreach Campaigns`.
2. Click `Donations`.
3. Review the summary cards and currency totals.
4. Use search or filters to narrow the donation list.
5. Review whether each record is `Received` or `Pledged`.

### Notes

* Donation records can include both cash and item-related activity.
* Status helps your team separate promised support from what has already arrived.

## Donor Directory

Use the donor directory to review everyone who registered or gave through outreach campaign pages.

![Donor directory screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/outreach-donor-management/donor-directory.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=1481dcaea007487a472915aba0d37cff)

### What You Can Do

* Search donors
* Filter donors by form
* Choose which columns to display
* Open donor details

### Steps

1. Open `Outreach Campaigns`.
2. Expand `Donor Management`.
3. Click `Donors`.
4. Use the search box or form filter to narrow the list.
5. Use `Columns` if you want to change what the table shows.
6. Click a donor name or the view icon to open donor details.

### Notes

* Donors appear here after they register through campaign donation pages.
* Column selection helps your team focus on only the details needed for follow-up.

## Donor Details

Use the donor details drawer to review supporter information without leaving the donor list.

![Donor details drawer](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/outreach-donor-management/donor-profile.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=07bc0463f7ee2d74e29d0d4955a35524)

### What You Can Do

* Review contact information
* See additional form responses
* Review donation statistics
* Open donation history

### Steps

1. Open `Outreach Campaigns`.
2. Click `Donor Management`, then `Donors`.
3. Click a donor name or the view icon.
4. Review the `Information` tab.
5. Switch to `Donation History` when you need the full giving record.

### Notes

* The donor details view opens in a side drawer for quick review.
* The information shown can vary depending on the donor form used during registration.

## Donor Forms

Use donor forms to decide what extra information supporters should provide when they engage with a campaign.

![Donor forms screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/outreach-donor-management/donor-forms.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=9e026fff2159090d5a97586edc4fc838)

### What You Can Do

* Create a donor form
* Search forms
* Filter forms by status
* Review how many fields a form contains
* See whether a form is already attached to a campaign

### Steps

1. Open `Outreach Campaigns`.
2. Expand `Donor Management`.
3. Click `Donor Forms`.
4. Use search or the status filter to find the form you want.
5. Click `Create Form` when you need a new donor form.
6. Review whether a form is already attached before making changes.

### Notes

* Attached forms stay linked to the campaign that uses them.
* Donor forms are useful when you need more than basic name and email details.
* Donor Forms is separate from the top-level [Forms product](/product/forms).
  Use Donor Forms for campaign-specific supporter information and Forms for
  broader church intake and follow-up.
* A reviewed Forms response can create an Outreach review reference, but it
  does not copy the response into donor records.

## Campaign Analytics

Use analytics to monitor campaign performance and share progress with leadership or your fundraising team.

![Campaign analytics screen](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/outreach-donor-management/campaign-analytics.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=3df6f3522e2e0411998b327fefa243d6)

### What You Can Do

* View total campaigns and active campaigns
* Review total cash pledged and total donors
* Filter by time period
* Filter by campaign status
* Switch between `Overview`, `Campaigns`, `Donations`, and `Trends`
* Review status distribution and monthly trends

### Steps

1. Open `Outreach Campaigns`.
2. Click `Analytics`.
3. Choose the time period you want to review.
4. Apply a campaign status filter if needed.
5. Switch between the analytics tabs to review the metrics you need.

### Notes

* Analytics is especially useful for reporting and campaign follow-up meetings.
* Filters help teams review the same time window before making decisions.

## Public Campaign Pages

Use the public campaigns page to show all active outreach opportunities in one supporter-friendly experience.

![Public campaigns page](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/outreach-donor-management/public-campaigns.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=ca9da5a1e8e96300cb69b09a386be195)

### What You Can Do

* Browse all active campaigns
* Search public campaigns
* Open an individual campaign page
* Share a clean public giving experience with supporters

### Steps

1. Open the public campaigns link.
2. Review the campaign cards on the page.
3. Use search if you need to narrow the list.
4. Click `Donate Now` on the campaign you want to open.

### Notes

* The public campaigns page is designed for supporters outside the admin dashboard.
* This page can display multiple active campaigns at the same time.

## Public Donation Flow

Use the campaign detail page to review the full campaign story and start the donation process.

![Public campaign detail page](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/outreach-donor-management/public-campaign-detail.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=9ec9fa73b9d667c59ae8ee7e181ecc9b)

### What You Can Do

* Review the campaign description
* See whether the campaign accepts items, cash, or both
* Review timeline and delivery information
* Review campaign progress
* Start the donation process

### Steps

1. Open a public campaign page.
2. Review the campaign details and item needs.
3. Click `Make a Donation`.
4. Sign in if prompted.
5. Continue with the donation steps shown on screen.

### Notes

* The current public experience asks supporters to sign in before completing a donation.
* Campaign detail pages help donors understand what is still needed before they give.

## Public Campaign Payment Page

Use the public payment page to review a donation summary before the supporter completes payment.

![Public campaign payment page](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/outreach-donor-management/public-campaign-payment.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=d06e45b5cef6d96d3ddd9a3a58a940cc)

### What Supporters Can Do

* Review the campaign name and donation amount
* Confirm donor name, email, and notes
* Continue to payment after signing in

### Steps

1. Open a public campaign page.
2. Start the donation flow.
3. Review the donation summary on the payment page.
4. Confirm the donor details are correct.
5. Sign in and continue with the payment options shown for that church.

### Notes

* The page shows the donation summary before the payment is completed.
* Payment options appear after the supporter signs in.

## Public Donor Profile Page

Use the public donor profile page to give returning supporters one place to review their donor account after sign-in.

![Public donor profile sign-in page](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/outreach-donor-management/public-donor-profile-sign-in.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=63d128d020ffadd889f4cfe13b9cb794)

### What Supporters Can Do

* Open a public donor profile page
* Sign in before viewing donor details and giving history
* Return to the profile page to review their account

### Steps

1. Open the public donor profile page.
2. Use the profile sign-in option.
3. Return to the donor profile page after sign-in.
4. Review the donor details and giving history shown on the page.

### Notes

* Before sign-in, the page shows a `Sign In Required` message instead of donor history.
* After sign-in, supporters can review their donor profile and past donations in the same public experience.


# Outreach, Missions and Local Presence
Source: https://docs.thefaithapp.com/product/outreach-missions-local-presence

Coordinate initiatives and mission teams, publish trusted local services, and share reviewed community impact.

Outreach Mission Control brings initiatives, mission applications, community
partners, team preparation, prayer, verified service time, and reviewed impact
stories together. It builds on existing Outreach Campaigns and Events instead
of creating separate giving or registration systems.

## Set Up an Initiative

1. Create or open an active Outreach Campaign.
2. Open `Outreach Campaigns > Mission Control > Initiatives`.
3. Choose an outreach event, mission trip, service project, or fundraiser.
4. Choose direct signup, a reviewed application, a linked Event registration,
   or closed signup.
5. Optionally link a community partner, add capacity and deadline, publish a
   prayer focus, and deliberately enable organization-level map coordinates.

> [!WARNING]
>
> Mission applications are for adult members and collect only motivation,
> experience, availability, and accessibility or support requests. Do not ask
> for travel documents, immigration, medical, child-travel, or financial-account
> information in this workflow.

For adult mission trips, applicants can open `Private travel readiness` after
applying. This separate consented record encrypts passport, visa, immigration,
medical-clearance, vaccination-readiness, and emergency-contact fields.
Authorized reviewers open it from the application card; access and decisions
are audited. Members may delete it, and a retention job purges its contents 90
days after the trip. Child and youth travel uses linked Events and the existing
guardian, waiver, and protected-session safeguards.

## Review and Prepare a Team

The restricted `Applications` section lets authorized reviewers approve,
waitlist, or decline mission applications. Private support requests do not
appear on public pages or in ordinary campaign administration.

Use `Readiness & Updates` to add packing items and training steps. A training
step can include instructions, a resource link, and staff verification.
Approved members see only their own readiness in the mobile Outreach Hub.

Updates can be public, limited to the approved team, or limited to members with
a settled gift for that campaign. A pledge or failed checkout does not grant
donor-update access.

## Publish Trusted Local Services

Use `Partners & Services` to maintain organization contact details, opening
hours, accessibility, eligibility, referral instructions, service category,
and optional public map coordinates. Keep unconfirmed information in draft.

`Import partner directory` previews a CSV with row-level errors before import.
Imports are limited to 500 valid rows, use a stable external ID for repeatable
updates, and are always saved as drafts with public map visibility off.

`Preview coordinates from locality` returns organization-coordinate
candidates without saving anything. Review the candidate, then explicitly save
and publish the map pin. `Plan partner visits` orders two to twenty deliberately
published partner pins and can open them in a maps app. It uses straight-line
stop ordering—not live road or traffic optimization—and never uses member or
beneficiary locations.

After checking a published profile, use `Save and re-verify`. Information that
has not been verified for 90 days is visibly marked so visitors know to contact
the organization before relying on it.

> [!WARNING]
>
> Partner profiles describe organizations. Never store beneficiary addresses,
> service usage, referrals, attendance, or case notes in the directory.

## Verify Impact

Approved members submit service time in the mobile Outreach Hub. Staff verify
or reject it, and only verified minutes enter public impact totals.

The dashboard may combine verified time, approved participants, prayer
supporters, delivered campaign items, settled giving, and staff-recorded
aggregate measures. Aggregate measures must not contain names or a beneficiary
roster.

Members and public visitors can offer stories with publication consent. Every
story stays pending until restricted staff review it. Remove contact details,
private care information, unapproved names, and identifying details about
children or beneficiaries before approval.

## Member and Public Experiences

The mobile `Outreach Hub` provides Explore, My team, Services, and Impact areas.
Members can join or apply, withdraw, pray, complete readiness, open training
resources, submit service time, and offer a story.

The public `/{church}/outreach` page shows current initiatives, a searchable
service directory, deliberately published map links, aggregate impact, and
reviewed stories. It does not expose team rosters, donor identity, applications,
private notes, or beneficiary records.

## Giving and Dependency-Gated Integrations

Fundraising continues through the existing Outreach Campaign checkout and its
configured Stripe, PayPal, or Flutterwave webhooks. Mission Control does not
create another payment ledger or require another webhook.

Transport manifests, vehicles, rooms, and equipment remain gated on capability
14\. Cross-church trips and shared partners remain gated on capability 18. AI
ranking, rewriting, scoring, and recommendations remain gated on capability 17.

For campaign creation and donor workflows, read
[Outreach and Donor Management](/product/outreach-and-donor-management).


# Pastoral Care
Source: https://docs.thefaithapp.com/product/pastoral-care

Receive confidential member care requests and coordinate safe, accountable follow-up.

Pastoral Care gives members a private place to ask their church for help and
gives authorized staff one organized workspace for follow-up.

Members can request general care, hospital or home visits, new-baby support,
counseling, benevolence, grief, illness, crisis support, pastoral follow-up,
wedding preparation, baby dedication, funeral support, relocation support, or
a pastoral recommendation. Requests do not appear in community feeds or public
member directories.

> [!WARNING]
>
> Pastoral Care is not an emergency service. If someone may be in immediate
> danger, use the emergency and safeguarding process appropriate to your
> location and church. Do not wait for a dashboard response.

> **For members**
>
> Ask for care, choose who may see it, follow progress, and control private
> follow-up preferences.

> **For caregivers**
>
> Own permitted cases, plan the next step, coordinate visits, and keep a
> minimal accountable record.

> **For care leaders**
>
> Set permissions, response coverage, consent boundaries, retention, and
> review practices before rollout.

> **For app teams**
>
> Offer the same member-owned experience in a church app through the public
> Pastoral Care API.

## Start With the Right Workspace

| Need | Open |
| - | - |
| Review and own confidential member requests | `Church Management > Pastoral Care > Care Requests` |
| Schedule visits, availability, and response coverage | `Church Management > Pastoral Care > Coordination` |
| Review member-approved dates and due follow-up | `Church Management > Pastoral Care > Life Moments` |
| Review consent-backed signals | `Church Management > Pastoral Care > Care Radar` |
| Schedule a homebound shared phone line | `Church Management > Pastoral Care > Care Programs` |
| Coordinate a funeral or wedding | `Church Management > Pastoral Care > Rite Runsheets` |
| Cover a caregiver's planned absence | `Church Management > Pastoral Care > Coverage Mode` |
| Plan upcoming preaching and review Scripture history | `Church Management > Pastoral Care > Preaching Plan` |

## Before You Start

Before inviting members to use Pastoral Care:

1. Name the leader accountable for safeguarding and response quality.
2. Give `Pastoral Care` only to staff who should see ordinary cases.
3. Give `Sensitive Pastoral Care` only to the smaller group permitted to see
   pastoral-only, counseling, benevolence, crisis, and restricted life-moment
   information.
4. Confirm who owns new requests during weekdays, weekends, and staff absence.
5. Agree on your urgent-care and emergency handoff process.
6. Review the configured closed-case retention period.
7. Submit a test request and practice assignment, follow-up, resolution,
   withdrawal, and content removal before announcing the feature.
8. If you will use the homebound phone-companion line, connect an active
   Twilio account with a voice-capable number and confirm that the server
   scheduler runs every minute. Follow the [Twilio setup
   guide](/product/twilio-setup) for account limits, Voice geographic
   permissions, billing, and live callback QA.

## Where Members Find It

Members open `Connect` in the mobile app and tap `Pastoral Care`.

From there, a member can:

* Share a new confidential care request.
* Choose how soon they need follow-up.
* Choose in-app, phone, text, or email contact.
* Review active and past requests.
* See whether a caregiver has been assigned.
* See the next scheduled follow-up when one is available.
* Review scheduled care visits, the assigned caregiver, and the information
  needed for the visit.
* Review a new-baby support plan and the kinds of support being coordinated.
* Choose which private life-moment dates the care team may remember.
* Pause automated celebration messages during a sensitive season.
* Edit or withdraw an open request.

## Sharing a Care Request

To share a request:

1. Open `Connect`.
2. Tap `Pastoral Care`.
3. Tap `Request care`.
4. Choose the type of care.
5. Describe what the care team needs to know.
6. Choose the privacy boundary and urgency.
7. Choose a preferred contact method.
8. Confirm that the church care team may contact you.
9. Tap `Share confidentially`.

Counseling, benevolence, and crisis requests are automatically restricted to
pastoral staff. Other requests can be shared with the wider authorized care
team or restricted to pastoral staff.

Urgent and crisis requests show an additional safety notice. Pastoral Care is a
church ministry workflow, not an emergency service.

### Choosing a Privacy Boundary

`Care team` means authorized caregivers may see the request on a
need-to-know basis. `Pastoral staff only` restricts it to staff who also have
Sensitive Pastoral Care access.

Counseling, benevolence, and crisis requests always use the pastoral-only
boundary. This safeguard applies even if a member-facing app submits a wider
choice.

## The Staff Care Workspace

Authorized staff expand `Pastoral Care` under `Church Management` and open
`Care Requests`.

The workspace shows active, new, urgent, unassigned, and overdue totals. Staff
can search for a member and filter the queue by status, type, urgency, or
owner.

Opening a request lets an authorized caregiver:

* Assign an eligible same-church owner.
* Move the request from assigned to in progress and resolved.
* Schedule the next follow-up.
* Add confidential notes.
* Create and complete follow-up tasks.
* Record a private resolution summary.
* Review the safe activity history.
* Schedule and complete hospital or home visits.
* Create a new-baby support plan with dates, a coordinator, and requested
  support.

A caregiver must be assigned before care can move into active follow-up. Closed
requests cannot be reopened.

## A Reliable Daily Care Rhythm

A simple operating rhythm keeps urgent work visible without turning the
workspace into a surveillance system:

1. Review new, urgent, unassigned, and overdue totals at the beginning of the
   care team's working day.
2. Assign one eligible owner to each request that is ready for follow-up.
3. Agree on the next action and record the next follow-up date.
4. Use visits and tasks for concrete commitments rather than placing long
   narratives in notes.
5. Resolve a request only after the agreed care step is complete, then record
   the minimum useful resolution summary.
6. Review upcoming visits and response coverage before weekends, holidays, and
   planned caregiver absences.

When more detail is not needed for continuity or accountability, do not record
it.

## Coordinating the Care Team

Expand `Pastoral Care` under `Church Management` and open `Coordination` to see
the shared care schedule.

The coordination view shows:

* Upcoming visits for cases the current staff member is permitted to see.
* Primary and backup response coverage.
* Recurring weekly availability for each caregiver.
* Simple counts for active cases, open tasks, and scheduled visits.

Use `Schedule coverage` to assign a primary caregiver, an optional backup, and
the response window. Use `Edit availability` beside a caregiver to add or
remove their recurring weekly windows.

These counts help the team distribute ordinary work. They are not a workload
score, wellbeing assessment, or automatic overload warning. Coverage notes are
for operational rotation information only and should never contain member or
case details.

## Member-Approved Life Moments

Members open `Pastoral Care` and tap `Manage care preferences`.

Reminders are off by default. A member can:

* Allow birthday, grief, illness, crisis, or hard-anniversary follow-up
  separately.
* Choose in-app, phone, text, or email as the preferred contact method.
* Say whether a gentle message is welcome, the care team should ask first, or
  the date should be remembered without contact.
* Add a one-time or yearly private date and choose how many days ahead the
  assigned caregiver should be reminded.
* Pause, edit, or permanently remove a private date.

These dates are not community recognition posts. They create a confidential
staff follow-up only after the member opts in.

Authorized staff open `Life Moments` from the `Pastoral Care` submenu to review
due follow-ups, assign an eligible caregiver, and record the minimum encrypted
outcome needed for continuity. Restricted grief, crisis, and hard-anniversary
moments remain visible only to staff with Sensitive Pastoral Care access.

## Consent-First Care Radar

Authorized staff open `Care Radar` from the `Pastoral Care` submenu to review
supported signals that may need human attention.

Care Radar is disabled by default. An eligible administrator can enable it and
choose thresholds for:

* Confidential care cases that remain unowned.
* Confidential follow-ups that become overdue.
* A caregiver's active-case count reaching a simple review point.
* Consecutive recorded Community Group absences.

Community Group participation review also stays off for each member until that
member separately enables both Care Radar and group participation follow-up in
their Pastoral Care preferences.

Every signal remains a review prompt. It does not diagnose a member, assign a
wellbeing label, send a message, or open a care case. Authorized staff can
acknowledge or dismiss a visible signal and may add a minimum encrypted review
note.

The source-readiness list in the Care Radar view identifies enabled and
consented sources. General service attendance, guest continuity, household
attendance drift, serving decline, and stopped-serving review use their
authoritative histories and remain inactive until the church policy and member
consent allow them.

## Rites, Coverage Mode, and Preaching Planning

Authorized staff expand `Pastoral Care` under `Church Management` and open the
specific workspace they need.

### Funeral and Wedding Runsheets

Open `Rite Runsheets` to create a funeral or wedding planner from an existing
confidential care case. The workspace adds a ten-item starting checklist for
family communication, people, service details, venue, documents, music, and
practical logistics.

Staff can assign a coordinator, record the event date and venue, add only the
family preferences and private details needed for coordination, and add custom
checklist items. Checklist items and the runsheet move forward and cannot be
reopened after completion or cancellation.

### Caregiver Coverage Mode

Open `Coverage Mode` when a caregiver will be away. Select the caregiver,
the person covering, the date window, and a minimum encrypted handoff summary.
The workspace snapshots the caregiver's active assigned cases at that point.

The covering caregiver can record a per-case next action and see how many
tasks and activities were recorded during the coverage period. Ending coverage
hands open items back for re-entry review. This is a bounded absence workflow,
not a permanent transfer of care.

### Preaching Calendar and Scripture Ledger

Open `Preaching Plan` to record the scheduled date, audience, service,
speaker, title, series, Scripture references, and relevant liturgical or civil
moments. Preparation notes remain encrypted.

When a reviewed plan is marked delivered, its Scripture references contribute
to the Scripture ledger. The ledger starts with manual plans recorded in this
workspace. Older sermon upload dates are not treated as preached dates.

These three areas are staff-only. Members continue to see safe status,
follow-up, and visit information through their linked Pastoral Care case.

## Quiet Days and Milestone Messages

Members can add a quiet-day window for birthday, wedding-anniversary,
baby/family, or all celebration messages. The existing automated directory
birthday and anniversary reminder excludes the member while that suppression
is active.

A member can optionally allow a private pastoral acknowledgment and add
restricted guidance. The reason and guidance are not shown to the wider care
team.

## Scheduling a Visit

Open a care request and select `Schedule visit`. Choose a hospital, home, or
other visit, then set the caregiver, date and time, location, and only the
private instructions needed for the visit.

After the visit, select `Complete` and record the minimum outcome needed for
continuity. A scheduled visit can also be cancelled. Completed and cancelled
visits cannot be reopened.

Members can review their own visit schedule and safe visit details in the
mobile app. Staff coordination controls and support-plan notes are never shown
there.

## New-Baby Support Plans

When a member chooses `New-baby support`, authorized staff can create a support
plan in the same care case. Choose a coordinator, plan dates, and the requested
support, such as meals, visits, transport, supplies, or prayer.

Members can see the coordinator, dates, and selected support. Private
coordination notes remain staff-only.

## Homebound Sunday Phone Companion

The phone-companion line lets a small group of homebound members join one
audio-only shared line from an ordinary ringing phone. It does not require a
video app or smartphone.

Participation starts with the member. In the mobile app, the member opens
`Connect > Pastoral Care > Care Programs`, selects `Request care`, and chooses
`Homebound phone companion`. The request records consent and the member can
review its status with their other specialized care requests.

Authorized staff then open `Church Management > Pastoral Care > Care Programs`:

1. Enter a clear session title and future date and time.
2. Select at least two consented requests. A session can include up to ten
   participants.
3. Select `Schedule shared line`.
4. Leave the session for the server scheduler to launch at the chosen time, or
   select `Launch now` when an immediate test or service start is intentional.
5. Watch the participant statuses. The page refreshes active calls
   automatically and shows a safe provider error when a call cannot be placed.

A scheduled session can be canceled before launch. Cancellation prevents its
calls from being placed and avoids using Voice credit for that session. Once a
session starts calling, let the participant statuses reach their final state.

Each participant receives the same brief introduction and joins the shared
conference. Participants can then greet one another by name. The conference is
created with recording disabled; TheFaithApp does not offer a control to turn
recording on for this workflow. Twilio Voice and conference usage are billed to
the church's connected account. The workflow rings real telephone numbers;
Twilio's browser Virtual Phone and Twilio Video are not used.

## Rollout and Review

Start with a small care team and a test member account. During the first weeks,
review:

* How long new and urgent requests wait for an owner.
* Whether next follow-up dates are being kept current.
* Whether members receive the contact method they chose.
* Whether caregivers are recording only the minimum necessary information.
* Whether sensitive access is limited to the intended people.
* Whether weekend and absence coverage is clear.
* Whether withdrawn and resolved requests move through retention as expected.

Do not use active-case counts as a performance score. The number of cases does
not describe complexity, emotional weight, caregiver wellbeing, or quality of
care.

## Permissions

Pastoral Care uses two staff permissions:

* `Pastoral Care` allows access to ordinary care-team cases.
* `Sensitive Pastoral Care` allows access to pastoral-only, counseling,
  benevolence, and crisis cases, restricted life moments, and Community Group
  absence signals. It is also required for rite runsheets and caregiver
  absence coverage.

Preaching planning is available to staff who already manage audio or video
sermons and have access to the Pastoral Care workspace.

Changing the church's Care Radar policy requires both administrator access and
`Sensitive Pastoral Care`.

Hiding the dashboard link is not the security boundary. Requests are also
filtered by church and permission when they are loaded or changed.

## Privacy and Retention

Request details, contact details, notes, task content, visit location and
instructions, visit outcomes, support preferences, support-plan notes,
coverage notes, private life-moment titles and guidance, quiet-day reasons,
follow-up outcomes, Care Radar review notes, rite family and logistics
details, runsheet checklist content, caregiver absence handoffs, per-case next
actions, preaching preparation notes, and resolution summaries are encrypted.
Staff access and important workflow actions are recorded.

Notifications use general language. They do not place a member's identity,
contact details, request content, notes, task content, or resolution content in
the alert.

After a request is resolved or withdrawn, private content is kept for the
configured retention period and then removed. The minimum status and activity
history remains for accountability.

## Prayer Follow-Up

When authorized staff create a Pastoral Care handoff from an urgent prayer
request, the handoff opens a linked care case. The original prayer title and
description are not copied into the care case. Only the minimum coordination
note and source reference move across the boundary.

## Pastoral Care in a Church App

Third-party church apps can offer the same member-owned care-request,
life-moment, and quiet-day workflows through the supported `v1` partner API.
Only the member-facing mobile operations are public. Staff notes, tasks,
coordination, Care Radar review, rites, coverage, and preaching tools remain
inside the protected staff product.

Developers should follow the
[Pastoral Care integration guide](/api-reference/pastoral-care) and generated
endpoint reference.

## Troubleshooting

### A staff member cannot see a request

Confirm that the staff member belongs to the same church and has `Pastoral
Care`. If the request is pastoral-only or uses a sensitive care type, they also
need `Sensitive Pastoral Care`.

### A request cannot move to in progress

Assign an eligible caregiver first. The care workflow does not allow active
follow-up without a clear owner.

### A request cannot be edited or reopened

Resolved and withdrawn requests are closed. They cannot be reopened. After
retention removal, confidential request content also cannot be restored.

### A private date does not create follow-up

Confirm that the member enabled the master reminder setting and the matching
follow-up type, the private date is active, and an eligible caregiver is
assigned. A quiet day may also intentionally suppress celebration messaging.

### Care Radar does not show Community Group absence signals

The church policy, member Care Radar consent, and member Community Group
participation consent must all be enabled. The member must also have qualifying
recorded group attendance history.

### The wrong caregiver appears unavailable

Review the recurring availability record and the coverage date range. Coverage
Mode is a bounded absence handoff; it does not permanently reassign the
caregiver's cases.

### A phone-companion session does not launch

Confirm that the session is still scheduled, its time has arrived, the server
scheduler is running, and the church has an active Twilio connection with a
voice-capable number. A provider failure appears beside the affected
participant without stopping the other calls in that session.

### A member cannot be selected for a phone-companion session

The member must submit a Homebound phone companion request and have a valid
international-format phone number. Staff must select at least two eligible,
consented requests for the shared line.

## Extended Care Workflows

The **Care Programs** and related clergy workspaces now include:

* Consent-bound service, household, guest, group, and Volunteer review signals.
* Human-reviewed workload balancing, meal-train drafts, and approximate-zone
  visit ordering.
* Encrypted baptism testimonies linked to a member's published baptism pathway.
* Reviewed grief, holiday, anniversary, long-illness, prodigal, and sacrament
  cadence templates.
* A consented phone-companion line for homebound participation.
* Successor handoff dossiers, illustration consent and reuse history, and
  reviewed historical preaching analysis.
* Separate safeguarded workflows for recovery, confession, reconciliation,
  immigrant/refugee support, prison correspondence, foster/adoptive response,
  dementia support, and other sensitive care contexts.

Every Care Radar result remains a prompt for an authorized person. It never
diagnoses someone, sends an automatic member message, or opens a care case on
its own.


# Personalized Home
Source: https://docs.thefaithapp.com/product/personalized-home

See the parts of church life that matter to you today, without searching through the app.

Personalized Home turns the first screen of the mobile app into a simple view
of your church week. It combines your own commitments and connections with the
church's sermons, devotionals, events, and bulletin.

## Start with your week

Open **Home** in the mobile app to see:

* A personal greeting and an ordered list of useful next steps.
* Your next registered event, Community Group meeting, or serving commitment.
* Announcements from Community Groups you have joined.
* Sermons and saved moments you want to revisit.
* A listening card when you leave an audio sermon unfinished.

The app only shows sections that have something useful to say. If you have no
upcoming commitment or saved sermon, the normal church content remains easy to
reach without empty cards taking up space. When none of your personal sections
has an update, Home shows a quiet all-caught-up message so the screen still
feels intentional and welcoming.

If your church publishes a custom Home design, these personal sections appear
above that church-authored content. You keep the same commitments, suggestions,
saved media, and sermon resume experience without losing the layout your church
created.

Home headings, actions, dates, participation labels, commitment context, and
recommendations follow the language selected in the app.

## Use quick actions

The Home screen keeps five common actions together:

* **Give** opens in-app giving.
* **Prayer** opens the church prayer community.
* **Check in** opens upcoming events and registrations.
* **Chat** opens member conversations.
* **Sermons** opens the sermon library.

## Follow your suggested next steps

The **For you** section orders practical actions using the connections and
participation already recorded in your profile. It may help you choose a
campus, find a Community Group, explore an upcoming event, discover an active
place to serve, request prayer, or continue a pastor conversation you already
requested.

The app only shows a recommendation when its destination is available for your
church. A published Bible plan can open directly from this recommendation.
Membership-class and baptism steps stay hidden until those journeys are
connected to published pathways. Recommendations do not guess at private
spiritual, pastoral, or personal circumstances.

## Continue a sermon

When you stop an audio sermon after the opening moments, the app remembers the
sermon and your position on that device. Select **Resume** on Home to continue
where you left off. Finished sermons and items stopped near the end are removed
from the resume card automatically.

## Privacy

* Home only uses information attached to your signed-in church membership.
* Group announcements only appear for Community Groups you have joined.
* Saved sermon notes are only returned to the member who created them.
* Personalized Home data is cached for offline use and cleared when the local
  member session is cleared.


# Platform, Access and Integrations
Source: https://docs.thefaithapp.com/product/platform-access-integrations

Support member access needs, deliver signed events, and keep church data portable.

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.

> [!WARNING]
>
> 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**.

## Configure Integrations Where They Are Used

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](https://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.

Choose **Set up Zapier** or **Set up Make** to open the invitation for your
provider. Sign in to your own provider account and accept access to TheFaithApp.
If the button is missing, says **Setup required**, or the invitation does not
open, email [support@thefaithapp.com](mailto:support@thefaithapp.com) with your
church name, preferred provider, and the workflow you want to connect. Do not
include an automation key or password in that email.

### Connect Your Church

1. In Developers, choose **Create automation key** and give it a name for the
   connection, such as `Visitor welcome`.
2. 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.
3. 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.
4. 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.
5. 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.


# Prayer Community
Source: https://docs.thefaithapp.com/product/prayer-community

Help members share approved prayer requests, pray for one another, and follow up when prayers are answered.

# Prayer Community

Prayer Community gives members a shared church prayer feed inside the mobile app. It turns prayer requests into a simple community rhythm: someone submits a need, the church reviews and approves it, members pray, and the requester can later mark the request answered with a testimony.

This feature is church-scoped in the current release. Members see approved
church requests and eligible Community Group requests, not a public global
prayer wall. Leaders-only and pastoral-only requests stay out of member feeds.

## Where Members Find It

Members open Prayer Community from the `Connect` page by tapping `Prayer community`.

From there, they can browse approved requests, submit a new request, mark that
they prayed, return to their own requests for follow-up, or use a private
prayer journal.

If a refresh cannot finish, the app shows an error and keeps the prayer content
already loaded on the screen. Tap **Refresh** again when your connection
is ready. A failed refresh does not mean that your church has no prayer requests.

## What Members Can Do

* Submit a new prayer request from the mobile app.
* Choose the Church Prayer Wall, one of their active Community Groups, church
  leaders, or the authorized pastoral team as the request audience.
* Choose whether the request should appear anonymously.
* View approved requests shared by their church.
* Tap `I prayed` to show support for a request.
* See how many members have prayed for a request.
* Review their own submitted requests.
* Mark their own request as answered.
* Add optional testimony text when a prayer has been answered.
* Edit an active request and return it for review.
* Withdraw a request from member Prayer Walls.
* Filter the Prayer Wall between active and answered requests.
* Keep member-only journal prayers and private answered reflections.
* Copy a journal prayer into a moderated request when they want others to
  pray with them.
* Set daily, weekly, journal-specific, and prayed-request follow-up reminders.
* Open a verified prayer-team daily list and mark assignments praying or
  completed.
* Privately ask church leaders for urgent follow-up on an active request.
* Open a locked Prayer Room when staff arrange immediate live prayer with a
  verified prayer-team leader.

## Submitting a Prayer Request

Members use the Prayer Community submit flow when they want the church to pray with them.

Typical steps:

1. Open `Connect`.
2. Tap `Prayer community`.
3. Open the submit request action.
4. Enter the request title and description.
5. Choose who can see the request.
6. Choose whether to submit anonymously.
7. Submit the request.

After submission, the request follows the church approval process before it
appears in an eligible member feed. Editing an approved request also returns it
for review.

When a situation needs timely attention, the member can also ask leaders for
urgent follow-up and include a short private reason. This signal and reason
stay out of the Prayer Wall.

### Audience Choices

* **Church Prayer Wall:** approved requests can be seen by members of the
  church.
* **Community Group:** approved requests can be seen only by active members of
  the selected group.
* **Church leaders only:** the request stays out of member Prayer Walls.
* **Pastoral team only:** the request is encrypted and restricted to staff
  who have private pastoral prayer access.

Audience and anonymity are separate. For example, a member can share an
anonymous request with their Community Group or a named request with leaders
only.

### Private Pastoral Requests

Choose `Pastoral team only` when the prayer itself and the follow-up need a
smaller confidentiality boundary than the general church-leader workflow.

The member app explains this boundary before submission:

* The member's identity is shared only with authorized pastoral caregivers so
  they can follow up safely.
* The private content is encrypted and access is recorded.
* The request does not appear on a Prayer Wall, in a prayer-team list or
  digest, in a Prayer Room, or in a general export.
* Staff exports contain workflow metadata only, not the prayer, identity, or
  contact details.
* After the request is answered, withdrawn, or rejected, the church keeps the
  encrypted content for its configured retention period and then removes it.

A request cannot be changed into or out of the pastoral audience after it is
submitted. Create a new request when a different audience is needed.

## Approval and Moderation

Prayer Community uses the existing prayer request approval flow as the moderation gate.

Approved requests appear in the church feed. Pending, rejected, or unreviewed requests stay out of the feed. This helps churches keep sensitive requests, duplicate submissions, or inappropriate content from becoming visible to the wider community.

For admins and prayer teams, the practical workflow is:

1. Review incoming prayer requests.
2. Approve requests that are appropriate for the church feed.
3. Confirm that the selected audience is appropriate before approval.
4. Keep request status up to date so members see the right requests.

## Anonymous Requests

Prayer requests can be anonymous.

When a request is anonymous, the feed hides the requester identity. This lets members ask for prayer without exposing personal details publicly. Non-anonymous requests can show the member or display name so the church can recognize who is asking.

Use anonymous requests for sensitive needs, family situations, personal struggles, or any request where privacy matters.

## Praying for Requests

Members can tap `I prayed` on a request to show they prayed for it.

Each member can mark `I prayed` once per request. The count helps the requester know that the church is standing with them, without requiring every person to leave a comment or message.

## My Requests

The member's own requests are available for follow-up.

This area helps request owners see what they submitted, track whether the request is still active, and mark it answered when the situation changes.

Owners can also edit an active request or withdraw it. An edit returns an
approved request to the review queue. Withdrawal removes it from member feeds
without deleting the church's follow-up record.

### Urgent Follow-Up

Members can ask for urgent follow-up while submitting a request or from `My
Requests`. The member sees whether the request is awaiting review, approved,
declined, being handled, or resolved. A pending urgency request can be
cancelled.

Urgent follow-up is a private request for the church's ministry team; it is not
an emergency service. Members facing immediate danger should contact the
appropriate local emergency service.

After a leader approves the request, staff can assign an owner, acknowledge
the need, begin follow-up, and record resolution. If live prayer is
appropriate, staff can create a locked Prayer Room for the member and a
verified prayer-team leader. The member can open that room from their request.

### Prayer Room Connection Recovery

If a Prayer Room connection becomes unstable, the room displays
`Reconnecting...` and temporarily pauses microphone, camera, and speaker
controls. The member stays on the room screen while the app tries to restore
the connection.

If the connection cannot recover, the member sees `Try connection again`.
This requests a fresh room session without making them leave and find the room
again. If microphone access has been permanently denied, the app also offers a
shortcut to the device settings where access can be restored.

The room also shows the member's own connection quality. Opening `Connection
help` gives practical suggestions, including changing networks or reducing
video data when bandwidth is limited.

In a video room, choose `Use audio only` from Connection help to pause incoming
video and turn off your camera while keeping prayer audio, chat, and room
controls available. The app does not switch modes automatically. Choose `Show
video again` when the connection improves. Incoming video can return, but your
camera stays off until you deliberately turn it on.

If you switch apps or the room moves into the background, TheFaithApp stops
your microphone and camera from publishing. You remain in the room, and the
app does not silently turn either control back on when you return. A clear
message shows which controls stayed off so you can restore them when ready.
If audio-only mode was active, incoming video remains paused after returning.

Members can review and copy a support diagnostic when they need help. It
contains only the room reference, audio or video mode, connection state and
quality, participant count, retry count, whether audio-only mode is active,
whether microphone or camera publishing was paused after leaving the app, and
capture time. It does not contain the room title, prayer text, names, contact
details, chat, recordings, device identifiers, or an access token, and the app
does not upload it automatically.

## Answered Requests and Testimonies

Request owners can mark their own requests as answered.

When they mark a request answered, they can add optional testimony text. This gives the church a simple way to celebrate answered prayer without creating a separate testimony workflow.

Good testimony text is usually short, specific, and safe to share. Members should avoid including private details about other people unless they have permission.

## Private Prayer Journal

The `Journal` area is for prayers a member wants to keep completely private.
Journal entries do not appear in the Prayer Wall, the staff prayer inbox,
exports, prayer-team lists, or church analytics.

Members can:

1. Add a title and private prayer or reflection.
2. Edit the entry as the situation changes.
3. Mark it answered and add an optional private reflection.
4. Return an answered entry to active when they want to keep praying.
5. Delete the entry and its reminder permanently.

When a member chooses `Share request`, Prayer Community copies the journal
entry into a new request. The member still chooses an audience and whether to
appear anonymously, and the copied request follows church review. The journal
entry itself stays private and can be shared only once.

## Prayer Reminders

The reminder card at the top of `Journal` supports:

* A daily prayer time.
* A weekly prayer time on the member's chosen day.
* A one-time reminder for a private journal entry.
* A one-time follow-up for a request the member owns or has marked
  `I prayed`.

Reminder delivery uses the time zone in the member's communication
preferences. One-time reminders turn off after delivery; daily and weekly
rhythms continue until the member removes them.

For privacy, push notifications use a general journal message instead of
placing the private prayer description on the device lock screen. Tapping the
notification opens Prayer Community.

## Prayer Teams

Church staff can open `Prayer Teams` in the dashboard to create teams from the
church's already verified prayer volunteers. Each roster member has a leader,
coordinator, or intercessor role, an active or paused status, optional weekly
availability, and an explicit weekly-email preference.

The member app shows a prayer-team card only to active roster members whose
prayer-volunteer profile remains verified. Opening it creates a stable daily
list and lets the member mark each assignment as praying or completed.

Daily lists use these privacy rules:

* Approved church requests can be added automatically.
* Leaders-only requests require a deliberate staff assignment.
* Community Group requests never enter a prayer-team list.
* Pastoral-only requests never enter a prayer-team list or digest.
* Anonymous requests stay anonymous.
* Team screens and emails do not include requester phone or email details.

The weekly digest is sent on the team's configured local schedule to active,
opted-in, still-verified roster members. Each recipient gets at most one
delivery per team and week.

## Current Scope

Prayer Community currently focuses on the core church prayer loop:

* Member submission
* Church approval
* Approved church feed
* `I prayed` support
* Owner follow-up
* Answered requests
* Optional testimony text
* Anonymous display rules
* Church, Community Group, leaders-only, and pastoral-only audiences
* Owner editing with moderation review
* Owner withdrawal
* Active and answered Prayer Wall filters
* Member-private prayer journal with answered reflections
* One-time journal-to-request sharing through normal moderation
* Daily and weekly prayer rhythms
* Journal and prayed-request follow-up reminders
* Verified prayer-team rosters, roles, availability, and assignments
* Permission-safe daily prayer lists
* Weekly prayer-team email digests
* Private member-requested urgency with staff review
* Safe alerts to authorized church leaders
* Assigned urgent follow-up through acknowledgement, work, and resolution
* Bounded Pastoral Care handoffs that do not copy the prayer text
* Locked urgent Prayer Rooms with verified prayer-team leaders
* Encrypted pastoral-only requests with restricted access, access history,
  metadata-only export, and timed content removal

The following community expansion ideas are intentionally left for later phases:

* Public or global prayer walls


# Prayer Rooms
Source: https://docs.thefaithapp.com/product/prayer-rooms

Host beta audio and video prayer rooms with speaker controls, recording options, and room-specific giving.

# Prayer Rooms

Prayer Rooms let members gather live in the mobile app for hosted prayer, support, and ministry moments. A room can be audio-first, like a stage or group prayer call, or video-based for smaller face-to-face gatherings.

This release is marked as beta because live audio, video, recording, and giving all need real-device QA across different phones, browsers, networks, and church payment setups.

## Where Members Find It

Members open Prayer Rooms from the `Connect` page by tapping `Prayer Rooms`.

The button includes a `Beta` label so churches know the feature is available for testing and early use while final QA continues.

## What Members Can Do

* View live prayer rooms.
* View upcoming scheduled rooms.
* Create a room when their role allows it.
* Join a live room quickly.
* Speak when they are the host, moderator, speaker, or approved participant.
* Listen when they join as a listener.
* Mute and unmute their microphone.
* Turn camera on or off in video rooms.
* View who is in the room.
* Report a room when something needs review.
* Give toward a room goal when room giving is enabled.

## Audio Rooms

Audio rooms are designed for prayer gatherings where a few people speak and others listen.

They work well for:

* Morning prayer
* Intercession
* Pastoral prayer sessions
* Member support gatherings
* Short church-wide prayer moments

Audio rooms show participant count, speaker/listener state, mute state, and speaking indicators so hosts can understand what is happening without needing a large meeting layout.

## Video Rooms

Video rooms are designed for smaller or more interactive gatherings where seeing faces matters.

They work well for:

* Prayer team meetings
* Small group prayer
* Volunteer prayer check-ins
* Ministry support calls
* Scheduled pastoral care sessions

The video layout is intentionally compact. It does not try to show every participant as a large tile when a room grows. The main call stays readable, and participants can be reviewed from the participant list.

## Creating a Room

When creating a room, hosts choose the setup that fits the gathering.

Common options include:

* Room title
* Audio or video room type
* Participant limit
* Church, partner-church, or global discovery
* Room giving
* Prayer clips
* Recording consent
* Locked room
* Recurring room
* Scheduled start time

After a room is created, the host is taken directly into the room. This keeps the flow short: create the room, enter the room, and begin hosting.

During the Prayer Rooms trial, a church can host one live room at a time with up to 10 participants and 500 participant minutes per billing period. Prayer Rooms Plus allows larger rooms, more live room flexibility, and a higher included participant-minute allowance.

## Choosing Who Can Discover a Room

Hosts can keep a room inside their church, share it with selected partner churches, or make it discoverable across the wider network when their church has access to those options.

For a partner-church room, search by church name or location and select one or more churches from the results. The app saves the church details automatically, so hosts do not need to find or enter church IDs.

Partner-church and global rooms are public and unlocked so eligible members can discover and join them. Use a church-only room when the gathering should remain within the host church.

## Joining a Room

Members can join live rooms from the Prayer Rooms screen.

The app keeps the join flow short so members do not have to move through multiple setup pages. Once they join, the meeting controls are shown inside the room.

If a member is a listener, they join in listen-only mode. If they are allowed to speak, they can publish microphone audio.

## Roles and Controls

Prayer Rooms use role-based controls.

Hosts and moderators can manage the room. Speakers can talk when allowed. Listeners can join and listen without publishing audio unless their role changes.

Room controls can include:

* Leave room
* End room
* Mute or unmute
* Camera on or off
* Request to speak
* Start or stop recording when allowed
* View participants
* Report room

When a host ends the room, connected participants are removed from the live session.

## Participants

Rooms show a preview of current participants and a full participant list.

Participant state helps hosts and members understand who is active:

* Muted
* Speaking
* Listening
* Speaker or host role

This is especially useful in larger audio rooms where not everyone can be shown prominently on the main screen.

## Recording and Prayer Clips

Rooms can require recording consent before recording or prayer clips are used.

Recording controls are shown only to users who can manage the room. Prayer clips and transcripts are part of the recorded-room workflow and should be used only when the church has set the right consent expectations.

Good practice is to tell members when a room may be recorded and why clips may be used.

## Room Giving

Room giving lets a room include a giving action and optional goal amount.

When the church has a connected payment provider, members can give in the app. Native in-app gifts can be counted toward the room goal, so the room can show progress such as `USD 500 of USD 2,000`.

Supported native payment setup depends on the church account having at least one provider ready:

* Stripe
* PayPal
* Flutterwave

If the church does not have a native payment provider, the room can use an optional external giving link instead. External gifts open outside the app and are not counted in the room progress bar because TheFaithApp cannot track those external transactions automatically.

## Current Beta Notes

* Hosts can choose church-only, selected partner-church, or global discovery when their church has access.
* Partner churches are selected by searching for their church name or location.
* The mobile app labels Prayer Rooms as beta from the Connect page.
* Trial rooms support one live room at a time and up to 10 participants.
* Partner-church and global rooms stay public and unlocked.
* Room giving progress is shown only for native in-app gifts.
* External giving links are available as a fallback when native payment setup is not ready.
* Real-device QA should include audio permissions, camera permissions, WiFi, cellular, recording consent, room ending, and giving behavior.


# Find a starting plan
Source: https://docs.thefaithapp.com/product/pricing-plan-finder

Compare four capacity needs on the public pricing page before reviewing the full plan allowances.

Use **Find a starting plan** on the [pricing page](https://thefaithapp.com/pricing)
to compare your church's expected member, administrator, branch, and campaign
counts. No account is needed.

## Check your four counts

1. Enter the number of **member profiles** your church expects to keep.
2. Enter the number of **staff administrator accounts** your church needs.
3. Enter the number of **branch records** your church needs.
4. Enter the combined number of **email and SMS marketing campaigns** your team
   expects to schedule or send each calendar month.
5. Review the starting plan and the allowances shown beside your counts. Change
   a count to compare another scenario.

The finder selects the lowest published plan that covers all four counts. A
church with 80 member profiles, three administrator accounts, one branch record,
and four monthly campaigns matches Standard's capacity rather than Free's
one-campaign allowance.

Email and SMS campaigns share one monthly allowance. Include scheduled, sending,
and sent campaigns; preparing a draft alone does not use that allowance.

This checks only those four capacities. It does not check other product features
or allowances. Review the [full comparison](https://thefaithapp.com/pricing#compare-plans)
for needs such as forms, reports, giving funds, integrations, or Church Networks
before choosing a plan.

## Understand an Enterprise result

Enterprise's base price is **USD 149 per month**, including 2,000 member profiles.
Each additional started block of 500 member profiles adds **USD 10 per month**.
For example, 2,001 member profiles gives a base-plan price of USD 159 per month
when the other three counts fit its published allowances.

More than 100 staff administrator accounts, 20 branch records, or 100 monthly
campaigns does not match a published tier. The finder reports that limitation
rather than treating Enterprise as unlimited.

Displayed prices are monthly base-plan prices in USD. Optional add-ons and
external services, including messaging delivery and payment processing, are
separate. The result is capacity guidance, not a complete quote or confirmation
that every feature your church needs is included.

## Continue when you are ready

Your entered counts stay in the page and are not saved by the finder. Using it
does not submit an access request, create an account, or change a subscription.

After reviewing the complete plans, follow the
[reviewed access process](/product/client-onboarding) if your church wants to
begin. A starting-plan result does not approve an access request.


# Public Church Pages
Source: https://docs.thefaithapp.com/product/public-church-pages

Consistent church branding, responsive navigation, and focused forms across your public church pages.

# Public Church Pages

TheFaithApp hosts a small public website for every church. These pages need no sign-in and are meant to be linked from your own website, social media, printed materials, and the QR code on the dashboard.

## The Pages

| Page | What a visitor can do there |
| - | - |
| Visit | Plan a first visit: see service times, directions, and what to expect, and submit a plan-a-visit form. |
| Connect | Fill in the connect card after a service, with a message to the church. |
| Devotionals | Read the church's published devotionals, filter them by topic, subscribe by email, or get the app. |
| Campaigns | See active giving campaigns and give to one. |
| Outreach | Learn about outreach initiatives and how to take part. |
| Give | Give a one-time or recurring gift to the church's funds. |
| Prayer Request | Send a prayer request to the church. |

Where to manage each page's content:

* Visit and Connect: **Visitors** (see [New Visitor Journey](/product/new-visitor-journey)).
* Devotionals: **Devotionals** in the sidebar.
* Campaigns and Give: **Giving** (see [Giving and Finance](/product/giving-and-finance)).
* Outreach: **Outreach Campaigns**.
* Prayer requests arrive in **Pastoral Care** and **Prayer Community**.

## The Devotionals Page

* **Topics** are the tags you add to a devotional in the dashboard. They appear as chips under the search box, most used first, and a visitor taps one to filter the list. Each card also shows its topics.
* **Subscribe by email** adds the visitor to **Marketing → Email Subscribers** with the source "Devotionals". Use that list to send new devotionals out.
* **Get the app** appears when the church's mobile app link is configured, and opens the same store link as the dashboard QR code.

## Event Pages

Each public event has its own page, linked from the dashboard's event share button. Beside the event details sits a registration card that shows how many spots are left, the date to register for, and the questions you chose to collect. At the top of the card a visitor can add the event to **Google Calendar** or download it for **Apple / Outlook**, and **Share** the page.

To ask guests a yes/no question while they register, add **registration options** to the event under its registration settings, one per line, for example "Bring a dish". Each becomes a checkbox on the public page, and the guest's choices appear on their confirmation, in the occurrence workspace, and in the registrations export.

## One Header and Footer

Every public page carries the same header and footer, so a visitor who arrives on the giving page can find the connect card or the devotionals without going back to your website.

The header shows:

* your church logo and name, which return to the Visit page;
* links to Visit, Connect, Devotionals, Campaigns, and Outreach, with the current page highlighted;
* a **Give** button that opens the giving page (hidden on the giving page itself);
* the sign-in control, on pages that offer a member sign-in.

On smaller screens, open the church menu to find the page links and **Give**.
Connect cards, published forms, giving, and prayer requests use this compact
menu at every screen size so visitors can focus on completing their task.
The giving page does not repeat a link to itself.

Published forms show the church identity in the header and one clear form
title above the questions. Embedded forms keep their church identity inside
the form, without adding the shared navigation or footer.

The footer shows your church name, location, and email, links to your website, the prayer request form, and the connect card, and a "Powered by TheFaithApp" credit.

The logo, name, location, email, and website come from your church settings. See [Settings, Branding, and Customization](/product/settings-branding-and-customization).

## Share the Pages

Each page has its own link. The easiest way to get one is to copy the Visit or Connect link from **Visitors** in the dashboard. Every public page follows the same pattern, built from your church's public identifier:

| Page | Path |
| - | - |
| Visit | `/{church}/visit` |
| Connect | `/{church}/connect` |
| Devotionals | `/{church}/devotionals` |
| Campaigns | `/{church}/campaigns` |
| Outreach | `/{church}/outreach` |
| Give | `/give/{church}` |
| Prayer Request | `/prayer-request/{church}` |

`{church}` is the identifier you see in any link copied from the dashboard. Once a visitor is on one page, the header takes them to all the others.

## Place a Page Inside Your Website

If you embed a page in your own site, add `?embed=1` to the end of the link. The header and footer are hidden so the page sits inside your site's own navigation. [New Visitor Journey](/product/new-visitor-journey) shows how to embed the Visit and Connect forms step by step.

## Phones

The header keeps the church identity and menu button visible on phones. Tap
the menu button to expand the links below it; no sideways scrolling is needed.
Tap it again to close the menu. Keyboard users can also close it with Escape.

## Notes

* Published forms offer a retry for temporary loading failures. A failed
  submission keeps entered answers while the page remains open. If receipt is
  uncertain, retry without changing the answers so the same submission can be
  checked safely. Wait for **Response received** before closing the page.

* Form answers are not saved as a browser draft. Closing or reloading the page
  may lose unsent answers.

* The header is also hidden on a signed-in member's own profile page, which has its own navigation.

* Visitors of one church never see another church's pages, giving, or prayer requests.


# Search and the Attention Bell
Source: https://docs.thefaithapp.com/product/search-and-attention

Find any member, visitor, care case, or dashboard page from the header search, and let the bell tell you what needs a person today.

# Search and the Attention Bell

Two controls in the dashboard header work on every page: a search box that jumps you to a person or a screen, and a bell that lists the things waiting for someone to act.

## Before You Start

* Sign in to your admin account. Both controls appear once you are inside **Church Management**.
* Search only returns people and cases from your own church.
* The bell shows items you are allowed to work on. If you do not see care cases, your account does not have the pastoral care permission.

## Search From Anywhere

1. Click the search box in the header, or press **Cmd+K** (Ctrl+K on Windows) from any page.
2. Start typing a name, email address, or phone number. Results appear as you type.
3. Use the up and down arrow keys to move through the results and press **Enter** to open one, or click it. Press **Esc** to close.

Results are grouped:

| Group | What it finds | Where it takes you |
| - | - | - |
| People | Members by name, email, or phone. | The member's profile. |
| Visitors | People who filled in a connect card or plan-a-visit form. | The Visitor Inbox, filtered to what you typed. |
| Care | Open pastoral care cases by the member's name. | Pastoral Care. |
| Pages | Any screen in the sidebar, such as "Households" or "Devotionals". | That screen. |

## The Attention Bell

The bell sits beside your profile menu. A dot on it means at least one item needs a person. Click the bell to see the list:

| Item | What it means | Where the link goes |
| - | - | - |
| Overdue follow-ups | Visitor follow-up steps and member follow-ups that were due before today and are still open. | Visitor Inbox |
| Care cases without an owner | Care requests nobody has been assigned to yet. | Pastoral Care |
| Urgent care cases | Open care requests marked urgent. | Pastoral Care |
| Profile changes to review | Member edits waiting for approval under Change Requests. | Members |
| New form responses | Form responses still marked as New. | Forms → Responses |

Each line shows a count and opens the screen where that item is handled. When there is nothing outstanding the bell says so.

The list refreshes on its own every two minutes, so you do not need to reload the page.

## Tips

* The same "needs attention" list appears on the dashboard home page, so you can start the day from either place. See [Dashboard and Internal Tools](/product/dashboard-and-internal-tools).
* A care case shows in the bell as both "without an owner" and "urgent" if it is both. Assigning it removes it from the first line only.
* Type a phone number the way it was saved on the record. Partial numbers work.


# Sermons and Bible Formation
Source: https://docs.thefaithapp.com/product/sermons-and-bible-formation

Help members revisit messages, follow Bible plans, share Scripture, and build a gentle reading rhythm.

# Sermons and Bible Formation

TheFaithApp connects the sermon library, live services, and church-created
Bible plans in one member journey.

## What Members Can Do

* Browse sermon series, audio messages, videos, YouTube content, and live
  services.
* Keep audio playing in the background and use lock-screen controls.
* Download sermon audio for offline listening and remove it later.
* Search published sermon transcripts and jump to a matching moment.
* Save a timestamp, give it a title, and keep a private sermon note.
* Open published clips and share them.
* Continue with a giving, Community Group, or Event action selected by the
  church.
* Follow individual, church-wide, or family Bible reading plans.
* Mark reading days complete and continue with grace days after an interruption.
* Share the Verse of the Day as an image card.
* Add Scripture to a private memorization list and review it at a helpful pace.

## Organize Sermon Series

Sermon series use your existing media Categories.

1. Open **Categories** in the admin dashboard.
2. Create a category for the series and add an image if desired.
3. Assign audio and video sermons to that category.
4. Members can open **Sermons > Series** to browse the series and its messages.

## Publish A Sermon Clip

Only clips that are rendered and explicitly published are visible to members.

1. Open **Sermons > Videos**.
2. Open the clips tool for an uploaded video.
3. Generate or review the clip.
4. When the clip is ready, select **Publish to members**.
5. Use **Withdraw** if it should no longer appear in the member app.

## Add A Next Action To A Sermon

1. Open **Sermons > Audios** or **Sermons > Videos**.
2. Select the next-actions icon for the sermon.
3. Add a giving, Community Group, or Event action.
4. Choose a short label members will understand.
5. Save the actions.

The dashboard only accepts groups and events owned by the same church as the
sermon.

## Create A Bible Reading Plan

1. Open **Bible Reading Plans**.
2. Create a plan and choose **Individual**, **Church**, or **Family**.
3. Add each day in reading order.
4. Give the day a title, Scripture reference, and optional reflection prompt.
5. For a family plan, add a household conversation prompt. Do not place private
   child information in the prompt.
6. Choose whether the plan uses grace days and optional streak repair.
7. Publish the plan when it is ready.

Members can then enroll, complete days, and see supportive progress language.
After the first member starts a plan, its reading days stay fixed so later
editing cannot erase member progress. Archive that plan and create a new one
when the reading schedule needs to change.
Their progress and memorization reviews are not a leaderboard and are not
shown as spiritual scores.

## Configure Live Captions And Go-Live Alerts

* YouTube captions continue to be managed in YouTube Studio.
* For a church-managed stream, add an HTTPS WebVTT caption-file URL in
  **Streaming > Live Streaming**.
* Changing a stream from inactive to active sends one go-live notification for
  that transition.
* You may add an existing sermon media ID as the on-demand archive after the
  broadcast.

Automatic recording still depends on the streaming provider supplying a
verified recording webhook and a durable recording URL. Adding an archive ID
does not cause TheFaithApp to record the broadcast.

## Privacy And Safety

* Sermon notes belong only to the signed-in member.
* Memorization cards and recall ratings belong only to the signed-in member.
* Family plans contain household prompts but do not create child profiles or
  child participation records.
* Only published plans, published clips, and reviewed sermon insights appear
  to members.
* Offline sermon files stay on the member's device.

## Current Platform Boundary

Dedicated Roku, Apple TV, and Fire TV applications and screen casting are not
part of this release. Those experiences require separate application targets,
store signing, device testing, and release workflows.


# Settings, Branding, and App Customization
Source: https://docs.thefaithapp.com/product/settings-branding-and-customization

Manage church profile details, social links, email delivery, developer setup, white-label branding, domains, and mobile app customization in TheFaithApp.

# Settings, Branding, and App Customization

This guide covers the settings and customization areas used to manage church details, public branding, technical app setup, and the mobile app experience in TheFaithApp.

These tools include:

* Church profile
* Social media links
* Email settings
* Developer tools and Firebase setup
* White-label branding
* Custom domains
* Custom branding for public pages
* Brand & theme
* Navigation builder
* Page builder
* Component library
* Customization releases

## Before You Start

* Sign in to your admin account.
* Open `Settings` for church profile, social media, email, developer tools, and branding.
* Open `App Customization` from the six-product sidebar for `Page Builder`, `App Navigation`, `Component Library`, and `Brand & Theme`.
* Some setup steps, especially SMTP and Firebase, may require help from your technical team or provider.

## Church Profile

Use church profile settings to keep your church identity, contact details, and general organization information up to date.

![Church profile settings](https://mintcdn.com/thefaithltd/q9MkJNOGHbY9afCq/images/product/settings-branding-customization/church-profile.png?fit=max\&auto=format\&n=q9MkJNOGHbY9afCq\&q=85\&s=de3803bfb2f73806f0fa407687e328d7)

### What You Can Do

* Update the church name
* Update the main church email address
* Update location and website details
* Choose the correct timezone
* Update the church description
* Upload or replace the church logo

### Steps

1. Open `Settings`.
2. Stay on `Church Profile`.
3. Update the church information you want to change.
4. Upload a new logo if needed.
5. Click `Save Changes`.

### Notes

* Keep this page current because the same church details can appear across other parts of the platform.

## Social Media

Use social media settings to share your public church links with members and visitors.

![Social media settings](https://mintcdn.com/thefaithltd/q9MkJNOGHbY9afCq/images/product/settings-branding-customization/social-media.png?fit=max\&auto=format\&n=q9MkJNOGHbY9afCq\&q=85\&s=ff15404a3c0ba76b8d5d6e9d3897759f)

### What You Can Do

* Add or update Facebook
* Add or update Instagram
* Add or update X
* Add or update YouTube
* Add or update TikTok

### Steps

1. Open `Settings`.
2. Click `Social Media`.
3. Paste the links you want to publish.
4. Click `Save Changes`.

### Notes

* Use full public profile links so members are sent to the right page.

## Email Settings

Use email settings to control the sending address and delivery provider used for church emails.

![Email settings](https://mintcdn.com/thefaithltd/q9MkJNOGHbY9afCq/images/product/settings-branding-customization/smtp-email-settings.png?fit=max\&auto=format\&n=q9MkJNOGHbY9afCq\&q=85\&s=a698704a401656031ac6433f65fdf8ff)

### What You Can Do

* Enter the SMTP host
* Set the port and encryption method
* Add the email username and password
* Set the sending email address
* Set the sender name
* Adjust the timeout when needed

### Steps

1. Open `Settings`.
2. Click `Email Settings`.
3. Enter the SMTP details from your email provider.
4. Set the `From Email Address` and `From Name`.
5. Click `Save Configuration`.

### Notes

* This page is usually completed with details supplied by your email provider or technical team.

## Developer Access

Use Developer Access when connecting an external app to TheFaithApp member sign-in and API access.

![Developer tools settings](https://mintcdn.com/thefaithltd/q9MkJNOGHbY9afCq/images/product/settings-branding-customization/developer-tools.png?fit=max\&auto=format\&n=q9MkJNOGHbY9afCq\&q=85\&s=812a85f9309e835b27b2b1853199b24d)

### What You Can Do

* Copy or rotate the client key
* Register Flutter and React Native apps with guided package-name forms
* Add Redirect URLs for web callbacks and mobile deep links
* Copy a hosted member sign-in link
* Open the hosted sign-in page for testing

### Steps

1. Open `Settings`.
2. Click `Developer Access`.
3. Copy the client key.
4. For a Flutter app, click `Add Flutter app`, enter the package name ending in `.thefaithapp`, and click `Add app`.
5. For a React Native or Expo app, click `Add React Native app` and follow the same package-name pattern.
6. Add any other redirect URL that should receive member sign-in codes.
7. Copy or test the hosted member sign-in link.
8. Rotate the client key only when you are ready to update connected apps.

### Notes

* This area is usually handled together with a technical owner.
* Flutter and React Native apps return directly to the installed app, so a separate callback website is not required.
* Hosted member sign-in runs through TheFaithApp, even when your church uses a custom public domain.
* Client keys are public church-app identifiers, not authentication secrets. Member access still requires a signed-in member token.

## White-Label Branding and Domains

Use white-label branding to replace default app branding with your church identity and connect a public domain.

![White-label branding settings](https://mintcdn.com/thefaithltd/q9MkJNOGHbY9afCq/images/product/settings-branding-customization/branding-white-label.png?fit=max\&auto=format\&n=q9MkJNOGHbY9afCq\&q=85\&s=1aae96b33a77b2b1ace3b14c582e617d)

### What You Can Do

* Turn white-label branding on or off
* Review the branding preview
* Add a custom domain
* Remove a domain when it is no longer needed

### Steps

1. Open `Settings`.
2. Click `Branding`.
3. Stay on `White-Label Branding`.
4. Turn white-label branding on when you are ready to show your own identity.
5. Review the preview area.
6. Click `Add Domain` when you want the app served from your own church URL.

### Notes

* The page currently supports one custom domain per account.
* Domain setup may still require DNS or provider-side work outside TheFaithApp.
* After the domain is registered, TheFaithApp automatically recognizes it for
  secure dashboard-to-service requests. You do not need to ask support to add
  the domain to a separate browser access list.

## Custom Branding by Page

Use custom branding when you want specific public pages to have their own colors and visual styling.

![Custom branding settings](https://mintcdn.com/thefaithltd/q9MkJNOGHbY9afCq/images/product/settings-branding-customization/custom-branding.png?fit=max\&auto=format\&n=q9MkJNOGHbY9afCq\&q=85\&s=db349e8dfeec7359c4b1f12d341818dc)

### What You Can Do

* Choose a page type to customize
* Change the page color palette
* Add custom CSS
* Preview the public page look
* Copy branding from another page type
* Turn custom branding on or off

### Available Page Types

* Donations page
* Devotionals
* Outreach campaigns

### Steps

1. Open `Settings`.
2. Click `Branding`.
3. Open the `Custom Branding` tab.
4. Choose the page type you want to style.
5. Update colors or custom CSS.
6. Use `Preview` to review the result.
7. Click `Save Changes`.

### Notes

* This section affects public pages, not the main admin dashboard.
* Each supported page type can have its own visual treatment.

## Brand and Theme

Use Brand & Theme to control the global design language for the app customization workspace.

![Brand and theme editor](https://mintcdn.com/thefaithltd/JTa_BF3ZPpXhr8r5/images/product/settings-branding-customization/brand-theme.png?fit=max\&auto=format\&n=JTa_BF3ZPpXhr8r5\&q=85\&s=e37652897fa93dbc8f7c6a4a71f61982)

### What You Can Do

* Set the global color palette
* Choose the main typography style
* Adjust the default corner radius
* Choose the interface theme behavior
* Save a draft
* Restore the default design settings
* Preview the published app structure

### Steps

1. Open `App Customization`.
2. Click `Brand & Theme`.
3. Update the colors, typography, radius, or theme settings.
4. Click `Save Draft`.
5. Use the preview panel to review how the current design feels.
6. Publish when you are ready for the design to become part of the next release.

### Notes

* These settings act as the shared visual base for navigation, custom pages, and reusable components.

## Navigation Builder

Use the navigation builder to control the app tabs members can see and where each tab should go.

![Navigation builder](https://mintcdn.com/thefaithltd/q9MkJNOGHbY9afCq/images/product/settings-branding-customization/navigation-builder.png?fit=max\&auto=format\&n=q9MkJNOGHbY9afCq\&q=85\&s=abef3eab155d749190b4d94ae1c57a19)

### What You Can Do

* Rename navigation items
* Change navigation icons
* Reorder items
* Point items to system pages or custom pages
* Hide or show individual items
* Save a draft navigation setup
* Publish navigation changes

### Steps

1. Open `App Customization`.
2. Click `Navigation`.
3. Select the item you want to edit.
4. Update its label, icon, target, or visibility.
5. Reorder items when needed.
6. Click `Save Draft`.
7. Click `Publish Navigation` when you are ready to use the updated structure.

### Notes

* Published navigation is used by other app customization previews.

## Page Builder

Use the page builder to create and update custom mobile app pages.

![Page builder](https://mintcdn.com/thefaithltd/q9MkJNOGHbY9afCq/images/product/settings-branding-customization/page-builder.png?fit=max\&auto=format\&n=q9MkJNOGHbY9afCq\&q=85\&s=4c255a2bc288284995927a3b3ca50ca2)

### What You Can Do

* Create or select a custom page
* Add text, images, cards, buttons, spacers, dividers, sections, and reusable components
* Edit page details and route information
* Inspect and update individual blocks
* Upload an app bar logo for the page
* Save draft changes
* Publish a page
* Duplicate or delete a page

### Steps

1. Open `App Customization`.
2. Click `Page Builder`.
3. Select the page you want to edit.
4. Add or update blocks in the canvas.
5. Use the right-side inspector to change content and styling.
6. Click `Save Draft`.
7. Click `Publish` when the page is ready.

### Notes

* Published reusable components can be inserted into custom pages from this builder.
* Use the preview mode to check the page before publishing.

## Component Library

Use the component library to create reusable content blocks that can be placed in custom pages later.

![Component library](https://mintcdn.com/thefaithltd/q9MkJNOGHbY9afCq/images/product/settings-branding-customization/component-library.png?fit=max\&auto=format\&n=q9MkJNOGHbY9afCq\&q=85\&s=3c7af4223a092f817629f49f440e2341)

### What You Can Do

* Create reusable carousels
* Use manual content or a data source
* Review published components
* Open and configure existing components
* Publish reusable components for page-builder use

### Steps

1. Open `App Customization`.
2. Click `Component Library`.
3. Review the existing components or click `Add a component`.
4. Choose a template or data source.
5. Configure the component content and behavior.
6. Save and publish the component.

### Notes

* Reusable components help keep shared layouts consistent across custom pages.

## Customization Releases

Use releases to decide when published customization changes should become the live app experience.

![Customization releases dialog](https://mintcdn.com/thefaithltd/q9MkJNOGHbY9afCq/images/product/settings-branding-customization/customization-releases.png?fit=max\&auto=format\&n=q9MkJNOGHbY9afCq\&q=85\&s=2b8ec975a9971dbe9f6ada9b734661cd)

### What You Can Do

* Review recent release history
* See which release is live
* Turn `Use custom design` on or off
* Publish a new release

### Steps

1. Open `App Customization`.
2. Click the `Releases` button in the top bar.
3. Review the recent release list.
4. Turn `Use custom design` on when you want the app to use your released customization.
5. Click `Publish a release` when the currently published design, navigation, pages, and components are ready to go live.

### Notes

* A release is a snapshot of the customization that has already been published inside the editor.
* Releases help your team control when customization changes reach the live app.

## Current Product Notes

* `Settings > Branding` controls white-label and public-page branding, while `App Customization` controls the mobile app design workspace.
* Saving or publishing inside `Brand & Theme`, `Navigation`, `Page Builder`, or `Component Library` prepares customization content, but the live mobile app reads the latest release from the `Releases` dialog when `Use custom design` is turned on.


# Twilio Setup
Source: https://docs.thefaithapp.com/product/twilio-setup

Connect a church-owned Twilio account for SMS, approved WhatsApp delivery, inbound keywords, and the homebound phone companion.

TheFaithApp uses a Twilio account owned by the church. The church controls its
phone number, credentials, geographic permissions, compliance registrations,
usage, and billing.

This connection can support:

* SMS campaigns and staff replies.
* The signed SMS inbox, including `STOP`, `START`, `HELP`, join keywords, and
  text-to-give keywords.
* WhatsApp delivery when the configured sender is approved for WhatsApp in
  Twilio.
* Outbound, audio-only homebound phone-companion conferences.

> [!NOTE]
>
> Twilio's browser-based Virtual Phone is for messaging tests, not Voice calls.
> The homebound phone companion rings real telephone numbers. Twilio Video is
> a separate product and is not used by this workflow.

## What You Need

Before opening TheFaithApp, prepare:

* A Twilio account with two-factor authentication enabled.
* The production **Account SID** and **Auth Token** from the Twilio Console.
* A Twilio number with the capabilities you intend to use:
  * **SMS** for campaigns, replies, keywords, and the inbox.
  * **Voice** for the homebound phone companion.
* A funded, upgraded account for normal production use.
* Any registration or approval required by Twilio and the destination country.
* A small group of consented test recipients whose phone numbers are in E.164
  format, such as `+256...` or `+1...`.

Choose the number by capability, not only by country or price. Some Twilio
numbers support both Voice and SMS, while others support only one. Review the
capability badges before buying or assigning a number.

> [!WARNING]
>
> Trial accounts are useful for a first connection check, but they restrict the
> destinations that can be called or messaged. A verified destination can
> still be unavailable when it is outside the trial account's permitted
> country. Upgrade the account before treating trial results as production
> readiness.

## 1. Prepare the Twilio Account

1. Sign in to the [Twilio Console](https://console.twilio.com/).
2. Enable two-factor authentication for account owners and administrators.
3. Open **Phone Numbers > Manage > Buy a number** or **Active numbers**.
4. Choose a number with **SMS** capability. Also require **Voice** capability
   when the church will use the homebound phone companion.
5. Complete any country-specific regulatory or sender registration shown by
   Twilio.
6. Review pricing for the countries the church will message or call.
7. Set usage alerts and limit geographic access to the countries the church
   actually serves.

For outbound international calling, open **Voice > Settings > Geo permissions**
and enable the required low-risk destination ranges. Only enable high-risk
ranges when the church has a specific, reviewed need.

## 2. Connect Twilio in TheFaithApp

1. In the admin dashboard, open **Marketing > Integrations**.
2. In the Twilio card, select **Configure**.
3. Enter the Twilio **Account SID**.
4. Enter the Twilio **Auth Token**.
5. Enter the sending number in E.164 format, including the leading `+` and
   country code.
6. Turn on **Active**.
7. Turn on **Set as Default Provider** when Twilio should handle the church's
   SMS campaigns and replies.
8. Select **Save**.
9. Select **Test Connection**.

The connection test verifies the credentials against the Twilio account. It
does not send a message, place a call, prove that the number has SMS or Voice
capability, or confirm that a destination country is permitted. Complete the
live checks later in this guide.

TheFaithApp encrypts the saved Account SID and Auth Token and masks them when
the configuration is reopened.

## 3. Add the Incoming Messaging Webhook

The webhook is required for the SMS inbox, staff replies to inbound threads,
opt-out and opt-in handling, join keywords, and text-to-give keywords.

1. Save and activate Twilio in TheFaithApp.
2. Copy the **Webhook URL** shown in the Twilio configuration drawer.
3. In Twilio, open **Phone Numbers > Manage > Active numbers**.
4. Select the same number entered in TheFaithApp.
5. Find **Messaging Configuration**.
6. Under **A message comes in**, choose **Webhook**.
7. Paste the copied URL.
8. Select **HTTP POST**.
9. Save the Twilio number.

The URL is church-specific. Do not reuse one church's webhook URL for another
church or replace it with a dashboard page URL.

> [!WARNING]
>
> The webhook must be the public HTTPS URL shown by TheFaithApp. `localhost`, a
> private IP address, a temporary development tunnel, or the web-dashboard URL
> will not work in production.

TheFaithApp validates Twilio's signature before accepting an inbound message.
Repeated delivery of the same Twilio message does not create a duplicate inbox
message or repeat a keyword action.

## 4. Prepare SMS and WhatsApp Delivery

### SMS

* Confirm the configured number can send SMS to every destination country the
  church intends to use.
* Complete any required sender registration before sending campaigns.
* Collect and retain the recipient's consent before adding them to SMS
  outreach.
* Keep `Reply STOP to opt out` in campaign messages. TheFaithApp adds it when a
  campaign does not already contain an opt-out instruction.

### WhatsApp

WhatsApp works only when the configured number is also an approved Twilio
WhatsApp sender. Approval and template rules are managed in Twilio, not in
TheFaithApp.

For a temporary Twilio WhatsApp Sandbox test, each test recipient must first
join the sandbox using Twilio's join instructions. Do not treat a sandbox pass
as production approval. Before launch, move to the church's approved WhatsApp
sender and complete Meta and Twilio onboarding.

If the configured number is not enabled for WhatsApp, leave WhatsApp delivery
off and use SMS.

## 5. Prepare the Homebound Phone Companion

The phone companion places outbound calls. You do not need to create a TwiML
App, configure an incoming Voice webhook, or paste a separate Voice callback
URL into Twilio. TheFaithApp supplies non-recorded conference instructions and
a signed status callback for each participant call.

Before the first session:

1. Confirm the configured Twilio number has **Voice** capability.
2. Upgrade the Twilio account if it is still on trial.
3. Open **Voice > Settings > Geo permissions** and enable only the destination
   countries the church needs.
4. Confirm Voice and conference pricing for those countries.
5. Record each participant's consent in a **Homebound phone companion** care
   request.
6. Store each participant's real telephone number in E.164 format.
7. Confirm the TheFaithApp server scheduler runs every minute.

In TheFaithApp, authorized staff open **Church Management > Pastoral Care >
Care Programs**, select between two and ten consented requests, and schedule the
shared line. **Launch now** is available for an intentional live test.

The page refreshes active calls automatically. Normal final participant
statuses include `completed`, `busy`, `no-answer`, `failed`, and `canceled`.
One failed participant does not stop the remaining calls. Recording is always
disabled for this workflow.

## 6. Complete a Safe Live Test

Use test recipients who know a message or call is coming. Do not use a full
member list for the first test.

### Messaging test

1. Select **Test Connection** in the Twilio drawer.
2. Send one SMS campaign to a consented test recipient.
3. Confirm it appears in **Monitor > Logs > Messaging** in Twilio.
4. Reply `HELP` from the test phone and confirm an inbound thread appears in
   TheFaithApp.
5. Test a disposable join keyword.
6. Test `STOP`, confirm sending is blocked, then reply `START` to restore the
   test recipient's consent.
7. Schedule a second small campaign and confirm the server launches it at the
   selected time.

### Voice test

1. Create at least two consented homebound phone-companion test requests.
2. Schedule a session and select **Launch now**.
3. Answer the test phones and confirm they hear the introduction and join the
   same audio conference.
4. Confirm the session moves through calling or live state and then completes.
5. In Twilio, open **Monitor > Logs > Calls** and inspect the participant calls
   and Request Inspector.
6. Confirm the status callback received a successful `2xx` response.

> [!NOTE]
>
> A `busy` or `no-answer` result can still prove that Twilio accepted the
> outbound call and that the status callback worked. It does not prove the
> conference audio experience; answer at least two real phones for that check.

## Troubleshooting

| Symptom | What to Check |
| - | - |
| **Test Connection fails** | Re-copy the production Account SID and Auth Token from the same Twilio project. Rotate the token if it may have been exposed, then update TheFaithApp. |
| **Trial account says the destination is unverified** | Verify the test destination in Twilio. If it is outside the trial's permitted country, upgrade the account before retrying. |
| **Voice call is blocked** | Confirm the From Number has Voice capability and check **Voice > Settings > Geo permissions** for the destination country and number range. |
| **SMS sends but replies never appear** | Confirm **A message comes in** uses the exact TheFaithApp webhook URL with `HTTP POST`. If the number belongs to a Messaging Service, confirm whether the service defers to the sender webhook or overrides it. |
| **Twilio reports `403` for the webhook** | Confirm the webhook URL has not been rewritten by a proxy and that TheFaithApp still has the matching Auth Token. The public scheme and hostname must reach the API exactly as configured. |
| **Twilio reports `404`, `502`, or a timeout** | Open the webhook URL's hostname from outside the server, check TLS and DNS, and confirm the API is reachable. Do not use a local or temporary URL in production. |
| **Call stays at queued in TheFaithApp** | Check the Twilio Call Log Request Inspector for the status callback response. A failed callback prevents the dashboard from learning the final call state. |
| **WhatsApp delivery fails** | Confirm the sender is approved for WhatsApp, the recipient joined the sandbox when testing, and any required production template is approved. |
| **Scheduled SMS or phone sessions do not start** | Confirm the Laravel scheduler and queue workers are running. Scheduled SMS and phone-companion launch checks run every minute. |

## Server Readiness

This section is for the team operating TheFaithApp. Churches using the hosted
service do not need to change server settings themselves.

* Set `APP_URL` to the public HTTPS API origin, such as
  `https://api.thefaithapp.com`.
* Never leave `APP_URL` set to `localhost` or a development tunnel in a staged
  or production deployment.
* Preserve the original HTTPS scheme and hostname through the reverse proxy so
  Twilio signature validation uses the same URL Twilio called.
* Run Laravel's scheduler every minute and keep the queue workers healthy.
* Keep TLS, DNS, and the callback route publicly reachable from Twilio.
* Review Twilio Messaging and Call Logs after deployment and confirm callbacks
  return `2xx` responses.

## Security and Billing

* Treat the Auth Token like a password. Do not send it by email, paste it into
  support tickets, commit it to Git, or include it in screenshots.
* Enable two-factor authentication and usage alerts in Twilio.
* Rotate the Auth Token immediately if it is exposed, then update and retest
  the connection in TheFaithApp.
* Enable only the geographic destinations the church needs.
* Review messaging, Voice, conference, number rental, and WhatsApp charges in
  Twilio before launch.
* If the church stops using Twilio, turn the provider off in TheFaithApp before
  releasing or canceling the Twilio number.

## Twilio References

* [Twilio phone numbers and sender types](https://www.twilio.com/docs/numbers-and-senders/choose-sender-type)
* [Incoming messaging webhooks](https://www.twilio.com/docs/usage/webhooks/messaging-webhooks)
* [Voice dialing geographic permissions](https://www.twilio.com/docs/sip-trunking/voice-dialing-geographic-permissions)
* [Twilio trial limitations](https://www.twilio.com/docs/usage/trials)
* [Rotating a Twilio Auth Token](https://www.twilio.com/docs/iam/api/authtoken)
* [Twilio Virtual Phone messaging guide](https://www.twilio.com/docs/messaging/guides/guide-to-using-the-twilio-virtual-phone)


# Volunteers and Serving Teams
Source: https://docs.thefaithapp.com/product/volunteers-and-serving-teams

Build healthy teams, prepare schedules and worship plans, close coverage gaps, and help every volunteer arrive ready.

Volunteers & Serving Teams connects team rosters, healthy availability,
schedules, preparation, training, recognition, and worship planning. Leaders
work from the web dashboard, while members respond and prepare in the mobile
Volunteer Hub.

The dashboard keeps each task in a compact section bar and stacks forms below
their working lists on smaller screens. In the mobile app, profile, feedback,
availability, blockout, swap, and calendar actions open from the bottom of the
screen so the current assignment stays in context.

## Before You Start

1. Open `Volunteers > Ministries` and confirm each ministry is current.
2. Open `Volunteers > Schedule & Teams` and create the roles each ministry
   needs.
3. Decide which roles require safeguarding, a background check, references, or
   training before a person can be scheduled.
4. Give leaders only the scheduling, sensitive wellbeing, or worship-planning
   access their responsibility needs.
5. Ask members to review their reminder choices, availability, preferred
   serving load, and code of conduct in the Volunteer Hub.

> [!WARNING]
>
> Clearance fields record your church's review; TheFaithApp does not perform a
> background check or certify that a volunteer is safe or legally eligible.
> Follow your church's safeguarding policy and local requirements.

## Build Teams and Roles

Use `Teams` to add a ministry role, its preparation instructions, usual call
time, leadership state, and any required screening. Then add members to the
ministry, choose their role, and mark leaders or standby volunteers.

A member can be active, paused, or inactive without deleting their history.
Private leader notes and clearance details are visible only to people with the
sensitive wellbeing permission.

## Schedule a Service or Rehearsal

Open `Schedule` and create a service or rehearsal plan with its date, time,
timezone, location, and ministry. Add every needed position, then assign a
member or leave it open for an eligible team member to claim.

The coverage panel shows filled, confirmed, and unfilled positions. It also
warns about:

* A weekly availability mismatch or blockout
* An overlapping assignment
* A serving Sabbath window
* The member's monthly or consecutive-week limit
* A required clearance or training gap

Review warnings before publishing. Publishing sends invitations to assigned
members and exposes unfilled roles to active members of that ministry; it does
not silently confirm anyone.

Use a schedule template for a recurring pattern. A template can generate a
series of draft plans with the right number of roles. You can also duplicate a
previous plan and decide whether to retain its volunteers.

## Member Responses and Coverage

In the mobile `Volunteer Hub`, members can:

* Confirm or decline an invitation
* Request a swap
* Claim an eligible open role
* Check in near the scheduled serving time
* Review role instructions and the run of show
* Subscribe to their private serving calendar
* Reset that calendar link immediately if it was exposed
* Set weekly availability, blockouts, a serving Sabbath, and preferred load

When a role remains open, a leader can notify eligible standby team members.
The same availability, rest, load, conflict, and clearance checks still apply.

### Connect Your Calendar

In the mobile app, open **Volunteer Hub > My schedule** to connect Google Calendar
or Outlook. Staff with a member profile can also use
**Volunteers > Schedule & Teams > My schedule** in the web dashboard.
Choose a writable calendar and whether to include serving assignments,
registered events, or both. Times and cancellations follow the schedule in
TheFaithApp.

Declining a genuine invitation from the church's connected organizer calendar
updates your serving response after sync. A personal appointment copy has a
TheFaithApp response link instead. Open it to review your role, date, time,
timezone, and location, then choose **Accept assignment** or **Decline assignment**.
Declining requires a reason that your serving leader can see. The page works
without a staff account, and opening it does not record a response.

Keep the link private. If it has expired or the invitation is no longer
available, use the **Volunteer Hub** or contact your serving leader. You can
decline after accepting; contact your leader to change an already declined
assignment. Deleting a calendar entry does not decline an assignment. You can
reconnect, review sync history, or disconnect from the same section.

See [connected calendars](/product/events-and-volunteers#connect-google-calendar-or-outlook)
for organizer setup and troubleshooting.

## Care for Volunteer Health

The restricted `Wellbeing` section highlights patterns that may deserve a
human conversation: high load, long consecutive service, repeated declines,
attendance follow-up, or low post-service energy. These are prompts, not labels
or automated judgments.

Members can send a private post-service check-in about energy, support, and
whether they would serve again. Scheduling-only staff do not see private
comments or restricted wellbeing data.

Use `Training` to create a requirement for a ministry or role. A requirement
may link to a published Discipleship pathway, expire after a chosen period, and
send reminders while incomplete or nearing expiry.

Thank-you messages and serving milestones appear privately in the member's
Volunteer Hub when the member has chosen to receive recognition.

## Prepare a Worship Plan

Use `Worship Plan` to build an ordered run of show with songs, messages,
prayers, cues, owners, timing, stage positions, and production notes.

The song library can hold:

* CCLI number, default key, BPM, and notes
* Named arrangements with working key, capo, chord chart, and tempo
* Chord-chart links, rehearsal tracks, song files, stems, and references

Members open the published plan from their assignment. They can transpose a
stored chord chart, start an audible BPM metronome, and open the attached
preparation files. The CCLI usage report counts songs in published and
completed plans for a selected date range.

## Reminders and Communication

Assignment and training reminders respect church quiet hours, the member's
channel and category choices, and recorded email or SMS consent. Every reminder
also appears in-app.

For a broader update, use `Communications` and choose a Volunteer Team audience.
That audience includes active members of the selected serving ministry.

## Connected Operations Checks

Published service plans can now use the room and equipment inventory from
[Operations and Facilities](/product/operations-and-facilities) to identify
missing or conflicting operational requirements.

The **Payments & sync** area also lets authorized teams:

* Submit reimbursements and stipends for independent finance approval, without
  automatically sending money.
* Connect Planning Center, map a local ministry and people, and run repeat-safe
  schedule imports with visible run history.
* Request event-specific volunteer sharing with another church in an active
  network. The volunteer must consent and have a current portable clearance;
  raw background reports never cross church boundaries.
* Review explainable scheduling suggestions based on availability, load,
  conflicts, and eligibility. A person still makes every assignment.

Planning Center must be connected with a church-owned OAuth application before
live synchronization can begin.

See the [Volunteer Serving API guide](/api-reference/volunteer-serving) for the
authenticated endpoint and permission contract.