Emotional Wellness Digital Platform
Back to CRM

DEWP Access Architecture — Integration Spec

Revised 4 August 2026 · Self-signup + RLS gate model (no Base44 invite email).

Model in one paragraph

The CRM is the single source of truth for who may access the Digital Emotional Wellness Platform (DEWP). When an order is paid, the CRM pushes an approval record (email + access_state) to the DEWP and sends its own branded "Platform Access" email to the user containing a link to the DEWP. The user self-signs up on the DEWP with that same email + a password (no Base44 invite is ever generated, so no Base44 invite email is sent). The DEWP gates all wellness content with Row-Level Security: a logged-in user can only read content if their email exists in the pushed approval list with access_state = Active. A forwarded link lets a stranger create an account, but RLS shows them nothing — no paid resource is exposed.

1. CRM App Responsibilities (this app)

1. Push an approval record (not a user account)

pushUserToDEWP sends the user's identity (email, first/last name, organisation, CRM reference) + access_state (Active / Inactive). The DEWP stores this in an ApprovedSubscriber record. No user account is created on push and no invite is triggered.

2. Send the platform access email (CRM-owned)

The CRM sends a "Platform Access" CRMTemplate to each user. The CRM owns the wording and the DEWP link. Note: Base44's built-in SendEmail only reaches registered CRM users — external DEWP users require an email connector (Gmail or Outlook) connected by the admin.

3. Email must match the order

The email the user uses to sign up on the DEWP must match the email captured in the CRM order. The CRM invite email should instruct users to sign up with the exact email address it was sent to.

4. Access state is the master control

Active = access granted. Inactive = access revoked (soft removal). The CRM flips state and re-pushes; the DEWP enforces it on next login via RLS. No hard delete — the audit trail is preserved.

5. Rollover (renewals)

Continuing users stay Active (no re-push / re-email needed). New users become Prospect, receive the platform access email, and are pushed. Departing users are set Inactive and an Inactive state is pushed to revoke access.

6. Sync confirms alignment

syncDEWPStatuses verifies the DEWP's reported access state matches the CRM's master state and flags any mismatch. The CRM's master status is never overwritten by sync.

2. DEWP App Responsibilities (separate Base44 app)

1. Public app + Email/Password self-signup

Set app visibility to Public (Require login) and enable Email and password authentication only (disable OAuth/social). Anyone with the link can create their own account — no invite is sent, so no Base44 invite email is generated.

2. ApprovedSubscriber entity + RLS gate

Add an ApprovedSubscriber entity (email, access_state, crm_reference). Every wellness content entity is gated by RLS: a record is readable only if the logged-in user's email matches an ApprovedSubscriber with access_state = Active. This is the gate that blocks forwarded-link access.

3. Accept the push, no invite

receiveUserPush accepts access_state + identity and upserts the ApprovedSubscriber record via the service role. It must not call base44.users.inviteUser (that requires a user session and sends the unwanted Base44 email). The push arrives server-to-server with only an API key — use asServiceRole for all operations.

4. Report access state only

get_status returns the access state (active / inactive) from the ApprovedSubscriber record — not an account/invite lifecycle.

5. No invite management

Retire any manual "invite pending users" admin flow. Account creation happens via self-signup; access is controlled entirely by the pushed approval list + RLS.

3. Integration (CRM + DEWP combined)

1. Single direction of truth

CRM → DEWP for access state. The DEWP only reports its current state back for audit/confirmation. The CRM is master.

2. Push payload

Carries user identity (email, first/last name, organisation) + access_state + crm_reference. No invite-action field. Authenticated by x-api-key only (server-to-server, no user session).

3. Emails

The CRM sends every user-facing email (platform access, access removal) via an email connector. The DEWP sends none.

4. Forwarded-link protection

Self-signup is open, but RLS makes content invisible to anyone not on the CRM approval list. The link is not a secret — the approval list is.

Recommended implementation order

  1. DEWP: set Public (Require login) + Email/Password; disable social login.
  2. DEWP: add ApprovedSubscriber entity + apply RLS gate to all content entities.
  3. DEWP: update receiveUserPush to upsert ApprovedSubscriber (service role, no inviteUser); update get_status.
  4. CRM: connect an email connector (Gmail/Outlook) for external email delivery.
  5. CRM: create the "Platform Access" CRMTemplate and wire it into the send flow.
  6. CRM: confirm pushUserToDEWP sends access_state (already done).
  7. Both: verify end-to-end — push a test user, send the email, self-signup with the matching email, confirm content is visible; then set Inactive and confirm content is blocked.