MINISTRY WORKROOM

Ministry Workroom Suite Account Privacy Notice

Effective date: October 28, 2026
Version: mw-account-privacy-20261028-v1

On this page
  1. Who provides the service and what this notice covers
  2. Information the account service uses
  3. Why the information is used
  4. Connected apps and service providers
  5. Cookies, sessions and technical logs
  6. Access, export, correction and deletion requests
  7. Retention: approved policy and current operation
  8. Recovery copies and restoration
  9. Changes and contact

1. Who provides the service and what this notice covers

Carlo Orlando Leadership LLC, a limited liability company formed in New Jersey with its principal place of business in New Jersey, provides the Ministry Workroom shared account service at app.ministryworkroom.com. Contact Carlo@carloorlando.com about account information, privacy requests or this notice.

This notice covers the shared account service, including sign-in, church workspaces, roles, app access, account settings, export and deletion requests, and subscription metadata when billing is enabled. It does not replace the notices for the marketing website or connected apps. Those apps maintain their own product content, participant records and privacy processes.

The Suite does not itself store Church Staff Meeting meeting notes, Leadership 360 response content, Org Design Studio session contributions, Maximize response content or Coverage Kit content as shared account content. It can hold the account, access, usage and entitlement records associated with those apps. This scope statement does not authorize any change to a connected product or its audience.

2. Information the account service uses

Depending on the features actually used or enabled, account records can include:

A planned or implemented record model does not mean a feature is open to customers. At the October 28, 2026 service readback, public signup, customer billing and the newer account-admission/public-enrollment paths remained disabled. The operational status in section 7 explains what has and has not been enabled.

3. Why the information is used

The service uses account information to authenticate people; maintain church and app access; enforce roles, limits and entitlements; protect accounts; send transactional sign-in or invitation messages; process exports and verified deletion requests; resolve uncertain account or billing results; and keep the security and reconciliation evidence needed for those functions.

The one account-acceptance checkbox records agreement to Terms and acknowledgment of this notice. It is not a blanket processing consent, optional marketing permission, app participation consent or authorization to use another person's information. A connected app may need its own separate participant choice or authority check.

4. Connected apps and service providers

When a person starts and completes a connected-app sign-in, the Suite can provide the limited identity and access claims needed by that app's approved integration. App-specific identifiers are used to reduce unnecessary cross-app linkage. The existence of a Suite account, a private grant or a sign-in handoff does not itself create broader app permission.

The account service uses Cloudflare Workers and D1 for hosting and storage, Resend for transactional email and Cloudflare Turnstile for bot protection where configured. Stripe handles payment pages and processing when the separately configured payment service is enabled. The completed sandbox test is not customer billing activation. Each provider also processes information under its own applicable terms and notices.

Third-party connectors, general product-email activation, upstream Google sign-in and customer AI are not activated by this notice. The accepted, disabled Google connector links only a verified issuer and stable subject through deliberate account linking; it does not link or create accounts by email, retain provider access/refresh tokens, or supply a Terms receipt, church membership or app consent. No customer-AI inference processor is selected or active from this source work; provider research is not activation or a zero-retention promise. Accepted implementation work still requires its own accurate feature description, permissions and activation checks. This notice does not authorize private app data to be pooled or exposed.

5. Cookies, sessions and technical logs

The Suite uses a secure, host-only session cookie and temporary sign-in-attempt state for authentication and security. Its configured session expires after 30 days or seven days of inactivity, whichever comes first. Signing out ends that Suite session; connected apps manage their own sessions and access checks.

Hosting providers can keep technical request and execution logs, including requested URLs, methods and error information. The October 26, 2026 account readback showed invocation logging, dashboard persistence and 100% configured sampling; a fictional test confirmed that a requested URL's query string could be retained. The October 28 readback confirmed the same deployed Worker version as the earlier release; it did not separately re-read dashboard-level logging settings. Recovery transport code uses a request body for the covered operation, but that does not establish the behavior of every caller or eliminate provider logging.

The October 26 account readback showed the paid Workers plan and no configured external log destination for this Worker. Cloudflare's Workers Logs documentation, checked October 28, describes seven-day retention for that plan. This is a dated service-specific observation, not a guarantee that every request has a complete log or that other Cloudflare security/account logs, exports, the marketing website and connected apps follow the same period. Hosting logs are separate from the application's approved one-year security-record policy.

6. Access, export, correction and deletion requests

You can use available account controls to export information or request deletion, or contact Carlo@carloorlando.com to request access, correction, export or deletion or to ask us to review a response. We verify the request and the person's authority before acting. We preserve rights available under applicable law; the U.S. sales scope does not remove an existing person's privacy remedies.

If you are the only owner of a church with other members, ownership must be resolved before your account deletion can finish. Unresolved payment or subscription evidence may require a review to avoid an unsafe or duplicate financial result, but a software payment hold is not itself a legal basis to reject a privacy request.

Verified account deletion removes active account/profile information, linked identities, enrolled passkey records, sessions, memberships, app roles, per-app subject bindings and pending sign-in material through the implemented account-deletion controls. The Suite requests erasure or unlinking from connected apps used by the person. Each app has its own data and safeguards; a Suite deletion response does not certify instant or complete deletion in every app or provider.

Some church-level billing or security history can remain after active account deletion. Compact retention origins, nonreuse markers, invoice/schedule keys and explicit holds may remain after the related source record is removed; their lack of a direct email or actor field does not make them anonymous or unlinked. New invitation/recovery history can retain opaque account and pairwise identifiers during its security-retention period or a documented hold; those identifiers are pseudonymous/linkable, not anonymized. Requester-owned export is bounded and does not expose other people's identifiers, private invitations, credentials or operation keys. Church owners and administrators can receive permitted usage totals; this does not provide raw usage-unit references, operation receipts, hashes or maintenance permissions. Limits or retained information may require follow-up review through support. Current export has not been expanded to promise a complete account-level inventory of the new retention controls or all indirect billing relationships. Customer-AI metadata export can associate a record with the requester only while the current app-subject mapping exists; deletion of that mapping does not itself erase the retained AI record. Its safe export is limited to the requester-linked app/request/operation/state/timestamps, excluding internal financial fingerprints, budgets and other people’s records.

7. Retention: approved policy and current operation

The owner has approved the following prospective policy. Some required cleanup and activation work is not yet complete. Approval of the policy is not a claim that every period below already runs automatically.

Category Approved policy Current implementation/activation boundary
Account and login information Delete after a verified request, subject to resolving church ownership and applicable request handling. Active-data deletion controls exist; connected-app acknowledgments, retained security/billing evidence and provider recovery copies remain distinct.
Application security records One year. Existing audit cleanup is configured for 365 days. New invitation/authority-history cleanup is implemented locally as a prospective, guarded lifecycle but remains disabled; its required newer schema was absent in the last verified hosted ledger. Current authorization state needed by a live binding or retained invitation is not treated as an obsolete event log.
Usage history Two years. The prospective 730-day cleanup is not running. In the prepared update, eligible retired usage records and their related receipts and origins can be removed after retirement, dependency and hold checks. Evidence still required by a current scope is protected until the required retirement; a minimal generation record remains while that church/app scope can be reused. Existing or unknown-origin records are not automatically assigned a new cleanup start date.
Completed email and deletion-delivery records 30 days. Deletion notices remain until acknowledged by the app, then 30 days. Covered delivered, bounced, failed, cancelled or uncertain product-email records have a 30-day period after last update; delivery-webhook records have a 30-day period. Unacknowledged or otherwise unresolved states are retained for resolution, not silently expired. General product email remains disabled.
Rate-limit counters 24 hours. Cleanup is configured for 24 hours.
Closed churches without billing obligations 90 days. The prospective 90-day cleanup is not running. In the prepared update, remaining usage-accounting records for an eligible closed church can be removed with that church after the applicable checks. Residual usage, protected billing, unresolved AI and linked product mail can prevent deletion; the church period cannot shorten those records' separate retention requirements.
Settled billing records Seven years, with documented disputes or legal holds handled separately. Hosted billing evidence has no automatic purge schedule. Accepted code covers disabled settled-operation and superseded-reconciliation subsets, plus three limited transaction payload families: completed paid historical initial-checkout claims, resolved paid invoice-failure payloads and terminal restart-payment payloads. The required billing-retention updates were absent from the October 28 service readback and are not included in the next paired usage-accounting update. This is not the complete seven-year billing lifecycle. The reconciliation subset uses seven UTC calendar years from the first complete local zero-debt observation after supersession for known post-activation identities. The transaction subsets use seven UTC calendar years from their first complete qualifying database observation after separate activation, not the original payment date. There is no automatic legacy backfill; current, unknown, debt-bearing, referenced and held records remain protected. Activation requires a fresh bound preview and matching durable policy/configuration. Retained nonreuse keys and holds are not erased with the subset; broader records and church-deletion blockers remain unresolved. Automatic seven-year deletion is not running.

Configured cleanup is performed by scheduled jobs, so an eligible record is removed at a successful applicable cleanup, not necessarily at the exact anniversary. Accepted prospective cleanup excludes older or unknown-provenance records unless separately reviewed; current required authority state, unresolved dependencies and documented holds are handled explicitly. A disabled job, backlog or failed cleanup can affect actual removal timing.

Installing a retention schema is a storage change even when the cleanup switch is off: new source inserts may acquire unknown-origin provenance and persistent nonreuse keys. Installation does not itself activate cleanup, and no historical backfill or retrospective deletion is implied. Actual cleanup needs the distinct durable prospective activation, a fresh database-bound preview and applicable holds. Some minimal provenance, confirmed billing-outcome controls, holds and activation controls can remain after cleanup. The newer usage process can remove eligible retired-unit receipts, lifecycle records and origins while preserving the minimum generation record for a reusable scope; remaining scope records can be removed with an eligible closed church. This does not erase all older or unknown-origin provenance. Temporary cleanup selections are removed on successful completion or rolled back on failure.

No manual or retrospective production purge has been authorized by the prospective policy approval. Any such action needs its own reviewed scope, affected counts and recovery controls. This notice does not invent indefinite retention as the approved policy; it discloses the present implementation gap and the need to complete the approved schedule.

8. Recovery copies and restoration

Provider recovery features can retain earlier database states after information is removed from the active database. The October 26 account readback displayed a 30-day D1 Time Travel recovery window on the paid plan. Cloudflare's Time Travel documentation, checked October 28, describes that window and in-place restoration. This is not a promise that every record exists for that entire interval or that every provider-held copy disappears at its end.

Restoring a recovery copy requires manual operator reconciliation of erasure requests, revoked access, security actions, holds, nonreuse markers, activation and completed cleanup state before access or cleanup reopens. The retention controls do not automatically detect every restoration to an earlier state of the same database, and they do not automatically reconstruct retention holds, retired identifiers, activation or completed cleanup, including reconciliation-retention controls. A restore can revive removed operations or lose later controls. The account-erasure replay tool supports the older and updated service layouts, subject to checks for the exact installed layout, but it does not reconstruct all retention controls. Cleanup must remain disabled after restoration until this documented manual reconciliation is completed; this is an operator safeguard, not an automatically enforced restore feature. Separately exported backups, provider security/account logs and connected-app copies require their own handling. We do not promise instant deletion from all downstream systems or recovery media.

9. Changes and contact

Contact Carlo@carloorlando.com for privacy questions or requests. We will identify the reviewed notice by its actual effective date and separate version. When an existing preview account moves into covered public or paid use, the current Terms/Privacy acceptance flow must be completed; a software deployment or draft revision does not fabricate a receipt.