Use this runbook when an authorized council operator cannot reach RC Console or a Console-protected service. It is for restoring the intended access model, not bypassing it.
Know which gate failed
| What the operator sees | Check |
|---|---|
| Cloudflare says the account has no access | Access application policy and managed roster group |
RC Console loads, then returns 403 | Linked identity, current assignment, and operator gate |
| RC Console works, but Calendar denies one action | Position access map, Calendar role, and route-to-action policy |
| Every authorized person is denied | Steward rule, roster-group rule, roster sync, then email OTP |
| A recently removed person still gets in | Fresh private session, then roster sync |
Casework has a stricter Access policy. A Casework failure is not proof that RC Console is broken.
Stop before making it worse
Do not:
- delete the Access application, policy, or managed roster group;
- add an email domain,
Everyone, or a bypass rule; - add council members as one-off policy emails;
- change the Casework policy while restoring RC Console;
- copy tokens, email addresses, member lists, Access identifiers, or screenshots with personal data into an issue;
- restore the retired Notion roster path.
If the static steward rule is missing and no approved account can edit the policy, stop and contact the Cloudflare account owner. Do not create a broader temporary rule.
Expected front-door policy
In Cloudflare Zero Trust → Access → Applications → IHNYC RC Admin → Policies, confirm both of these allow paths exist:
- one static email rule for the steward;
- one rule that includes the managed IHNYC Roster Access group.
The steward rule is the out-of-band recovery path. Everyone else reaches the Console through the managed roster group. Operators do not maintain council membership by hand in Cloudflare.
Do not alter other Access applications while checking this policy.
Restore the smallest broken part
Clear a stale Access session
- Sign out with the Access logout route for the approved team domain, or open a private browser window.
- Start at
https://admin.ihnyc-rc.org. - Request a fresh email one-time code for the intended account.
- Confirm the identity shown in RC Console matches the account used to sign in.
If a fresh session works, do not change the policy.
Check email OTP
In Zero Trust → Settings → Authentication, confirm the email one-time-code login method is enabled and healthy.
- Do not add a second identity provider during an incident.
- Do not add a bypass when email delivery is delayed.
- If Cloudflare reports a provider incident, record the time and wait for recovery.
Restore the roster-group rule
If the application policy has the steward rule but not the managed group rule:
- Confirm the intended group is named IHNYC Roster.
- Add one allow policy that includes that group.
- Leave the static steward rule in place.
- Save, then verify with a fresh session.
Never replace the group rule with a list of individual council emails.
Repair a bad roster sync
RC Console D1 data is authoritative for the current council roster.
- In People, confirm the person exists and has the correct identity.
- In Positions & Access, confirm the current-term position assignment.
- In Term & Handover, confirm the active term.
- Check the Console health view and most recent roster reconciliation result.
- Run the supported Console roster reconciliation, or wait for the hourly run.
- Confirm the managed group count changes as expected without recording names.
If a recent assignment or handover caused the problem, undo that Console change and reconcile again. Do not edit the group membership directly and do not reconnect the deleted Notion roster databases.
Repair a broken application policy
Use the approved infrastructure inventory or the most recent sanitized audit record to restore only the two expected allow paths. Preserve their existing order and action. Do not recreate the whole application unless the account owner has confirmed it was deleted.
Check an in-app denial
If Access succeeds but RC Console returns 403:
- Confirm the person has a linked identity.
- Confirm the assignment belongs to the active term.
- Confirm the person has the council-admin capability needed for Console changes.
- Check for an unresolved assignment conflict or strict operator block.
Do not loosen the operator gate. Fix the identity or assignment that should grant access.
Check a service-specific denial
For Calendar or another integrated service:
- Confirm RC Console itself is reachable.
- Identify the denied action, such as
subscriber.revoke. - Check the position’s service role and access map in RC Console.
- Check the service health view and policy-service response.
- Confirm the service denies an unmapped action or a policy outage.
Do not add a service-side bypass. The policy check is designed to fail closed.
Verify recovery
Use fresh private sessions and record only pass/fail:
- The steward reaches RC Console through the static rule.
- One current council member reaches it through the managed roster group.
- An account with no current assignment is denied.
- The operator can open the expected Console areas.
- A permitted Calendar action succeeds and a non-permitted action is denied.
- The Casework application and policy are unchanged.
- The roster reconciliation and Access audit show the expected change.
Roll back
If a policy edit does not restore access, put the changed rule back exactly as it was and stop. If a Console data change was wrong, restore the prior assignment or term setting and reconcile once more. Do not delete the managed group to force a clean start.
Sanitized incident note
Copy this into the owning issue:
Time:
Reported symptom:
Boundary that failed: Access / Console / service authorization
Checks performed:
Smallest change made:
Verification: steward pass/fail; current member pass/fail; unauthorized account denied yes/no
Casework policy unchanged: yes/no
Rollback performed:
Follow-up:Production record
On July 19, 2026, a dashboard review confirmed the RC Admin application retained its static steward rule and gained the managed IHNYC Roster group rule. The Console-authoritative group was populated. One fresh current-council-member sign-in is still required before the operational verification item can be closed.
Sources
ihnyc-rc-landing/rc-admin/src/roster.tsihnyc-rc-landing/rc-admin/src/login.tsihnyc-rc-landing/rc-admin/src/middleware/auth.tsihnyc-rc-landing/rc-admin/src/cron/index.ts- Landing issue #325