Getting Care Compass fully live

The sequence

1. 1

   Deploy latest main

   Everything downstream depends on this one.

   Ahron

   A normal deploy, no special steps. Migration 0122 is already applied to the live database, so there is no ordering requirement and nothing to prepare first. It carries the A2P customer-profile fix, the editable review step, and the Cloud Run DNS work.

   Test before moving on

   I check the health endpoint returns 200 and that the served bundle now contains the new legal-structure field. That is a direct read of production, not an assumption.

   You refresh the A2P wizard and see a Legal structure dropdown on the business profile step. If it is not there, the deploy did not take and nothing after this will work.

2. 2

   Submit Attend's A2P registration

   The thing this has all been for.

   Trey

   Open the wizard on the Attend Home Care org and submit. Attend's legal structure should already read Limited Liability Corporation, filled in automatically by the migration's backfill, so there is nothing to type.

   Test before moving on

   I watch Twilio live and call out what lands. Expect a new secondary customer profile that reaches pending-review rather than stalling at draft, then a brand, then a campaign.

   Stalling at draft means the old bug; reaching pending-review means we are through and waiting on carrier vetting.

   If the brand step fails on a duplicate: that is the GoHighLevel hypothesis from two weeks ago finally surfacing, since TCR deduplicates brands by EIN. Different problem, known remedy, not a repeat of what we just fixed.
3. 3

   Delete the three orphaned drafts

   Housekeeping, so the next person sees one profile and not four.

   Me

   Three dead draft profiles accumulated while the bug was live, one per failed attempt. I remove them once step 2 has produced a real one, so we never delete the wrong thing.

   Test before moving on

   The profile list shows exactly two entries: the CLS Star parent and Attend's live registration.

4. 4

   Finish Meta business verification

   Only Ahron can do this, and it blocks the entire Meta side.

   Ahron

   Business Settings, then Security Center, then Start verification. The business details are already entered and matched against the correct public record, so what remains is the identity step.

   Meta asks for a government ID from a listed principal, and Ahron is the only principal on record, which is why this cannot be delegated. Choose his own name, upload the ID, then receive the confirmation code.

   Know before he starts: the confirmation code goes to whichever phone number was entered during setup. Confirm which phone that is out loud, so nobody waits on a text that arrived somewhere else.

   Test before moving on

   The business portfolio shows the business as verified, and the app creation flow stops refusing to continue.

5. 5

   Create the Meta app and its system user

   Straight after verification, while everyone is still on the call.

   Trey

   From inside Business Settings so the business owns the app from the moment it exists:

   • Apps, then Create a new app ID. Type Business, name Care Compass.
   • Add the Marketing API product, or the permissions we need are unavailable.
   • Users, then System Users, then add one and assign the ad accounts as assets.
   • Generate a token with ads_read, ads_management, business_management, leads_retrieval, pages_read_engagement, pages_manage_ads.

   Test before moving on

   Hand me the token and I call the Graph API with it live. A real response listing the business and its ad accounts is proof; anything else and we fix it while Ahron is still here.

6. 6

   Grant Secret Manager access

   Thirty seconds, and it unblocks production reading any of these credentials.

   Ahron

   Grant treyt@clsstarnv.com the Secret Manager Admin role on care-compass-beta-v1-503815. Read access already works; creating secrets does not.

   Worth doing even though only the Google credentials are ready today, because Meta's will need exactly the same treatment and this avoids a second round.

   Test before moving on

   Trey creates GOOGLE_ADS_DEVELOPER_TOKEN, GOOGLE_ADS_CLIENT_ID and GOOGLE_ADS_CLIENT_SECRET in Secret Manager. I confirm the names match what the deployment config expects, character for character, since a typo fails silently at boot.

7. 7

   Publish the Google OAuth app and verify branding

   Speeds up the Basic Access review already in Google's queue.

   Trey

   The branding form is already filled in: name, logo, homepage, privacy policy, terms, authorized domain and developer contact. Three actions remain, in the Google Auth Platform console:

   • Audience, then Publish app, moving it from Testing to In production.
   • Branding, then Verify Branding. It runs in a few minutes and shows errors inline.
   • Then Publish branding.

   Test before moving on

   Verification reports success, and I re-mint the refresh token. While the app sits in Testing the token expires after roughly seven days; once published it stops expiring, which is what production needs.

8. 8

   Wire the credentials into production

   The last step, and it rides along on the next ordinary deploy.

   Me

   Once the secrets exist, I put up a small change uncommenting the three Google entries in the deployment config so the app can read them at boot. No migration, so no ordering requirement.

   Test before moving on

   After the deploy that carries it, the boot log shows the environment flags with the Google credentials present rather than unset.

Worth deciding while everyone is together