Organization Settings Troubleshooting

This standard is the diagnostic runbook for organization and settings problems on the Platform: the failures that present as "it should work and it does not," worked by elimination. Administrative configuration failures rarely produce an error message; the failure mode is always something that should work and does not. The method is therefore fixed: verify each part in order, most common cause first, check the actual stored data at each step, and skip nothing because the operator is sure. The Organization Administrator and the System Administrator work this runbook; front-desk staff report symptoms and do not change settings to test a theory. Most problems below resolve in minutes when the order is followed.

A user cannot access the portal

Access is worked from the access record, because that is where access lives: and from the right record for the right population. Staff and administrator access is held in membership and roster records; customer access is held in customer account records, under Admin Users.

1. The most common misdiagnosis in this standard is treating an access problem as a password problem. Where the membership is inactive or the invitation was never accepted, no password reset helps, and each failed attempt frustrates the person further. The record is verified first, always.
2. For a staff member: does the membership record exist, is it active, and is its state what is expected? A missing record means the person was never added; the correction is an invitation, not a password reset. An inactive record means someone suspended them; the operator establishes who suspended them and why before reactivating, because the suspension may have been deliberate. A record still in invited state with no acceptance time means setup was never completed; the operator checks the invitation expiry: past expiry means the link is dead and the person needs a fresh invitation, not a resend of the dead one.
3. For a customer: is there a customer account record linking their customer record to a sign-in identity, and is its state active? An invited-but-never-activated account behaves exactly like a broken sign-in from the customer's perspective. The activation is resent.
4. Where the records are sound and access still fails, check the gate: administrative writes pass through the administration module check, and the Users screen itself requires the administration module at the right level for whoever is operating it. An administrator who cannot manage users usually lacks the grant themselves: the permission model applying to its own administration.
5. On resolving the problem, the operator tells the person what was actually wrong. "Your invitation had expired; a fresh one has been sent" teaches them the system is explicable. Unexplained corrections teach them it is mysteriously unreliable, and mysteriously unreliable is worse than broken.

A location will not switch

Three causes, told apart by where the operator looks

1. The location does not exist where the switcher looks. The administrative tenant switcher reads the current location system; the older location table is a different system, under Organization. Where the premises exist in one and the picker reads the other, the location will not appear however often it is clicked. The operator verifies the record exists in the system the switcher queries, with its active marker set: inactive locations are filtered by design, and that is deactivation working, not a fault.
2. The user has no scope there. A groomer assigned to the main salon legitimately has no access to another location's data; that is the permission model working correctly. "Correcting" it with broad access creates the over-permissioning problem Admin Users warns against. Multi-location access is granted expressly, with the reason recorded.
3. Genuinely duplicate locations. The live data holds a real example: near-identical main-location records across the two location systems, differing by dash characters. Where pickers show indistinguishable options, users choose at random and land in the wrong location's data, which presents as "switching does not work" or "the data is wrong." The correction is record hygiene: merge or deactivate the duplicates under Organization. Where doubling appears in a location picker, duplicates are checked before anything else is investigated.

Booking settings are not applying

The natural order is: is the value saved, is it saved in the right place, is the stored copy stale, is something more specific overriding it?

1. Read the actual setting: not the administrative screen, the stored value. The screen shows what was entered; only the store shows what the system kept. Booking rules are the booking settings under Booking Operations; runtime values are read through a short-lived stored copy refreshed on a 5-minute cycle. Where a setting was just changed and is not yet reflected, the operator waits out the refresh cycle before concluding it is broken; a significant share of apparent "settings do not work" reports resolve within one cycle.
2. Where the value is right and the behaviour still does not match, check hours and blackouts: hours and blackout records are enforced by the booking engine as binding, and a booking rule cannot offer a slot the hours forbid.
3. Check the online-booking switch itself: the master setting the public booking path reads. Debugging rules while the master switch is off is a particular kind of frustration; it is checked first among the rule-level causes.

The deposit requirement is not working

Deposits touch booking rules, payment processing, and the invoice, so the operator first narrows the symptom: is no deposit requested at booking, is it requested but the charge fails, or is it taken but not applied?

1. No deposit requested: verify the deposit requirement is actually on and an amount is configured: a percentage (the default is 25 percent) or a flat amount. The classic misconfiguration is enabling the requirement with no amount: the system is told to require a deposit of nothing, and nothing is what it requires. Both the switch and the amount are set.
2. The charge fails: that is the payment path, not the booking rules. The operator checks the processor linkage: the connection settings and the tenant's connection state, under Settings: and confirms the mode is live, not test. The Platform default is test mode with a placeholder account reference; a deposit charge attempted against that goes nowhere. The processor's console is also checked for incomplete onboarding: charges enabled but payouts not.
3. Taken but not applied to the invoice: that is a payment-to-invoice application problem, governed in the books by Deposits. The operator does not adjust the invoice by hand: manual adjustments on top of systematic misapplication compound the confusion. The exact sequence is documented: booking identifier, payment identifier, invoice identifier, amounts: and escalated with that evidence. Precise reports get corrected; vague ones get deferred.

Notifications are not sending

Notifications fail after the triggering action succeeds: the appointment books correctly, then the confirmation never arrives. The customer experiences unreliability, not a notification problem, which is why it surfaces as "customers say they never received the confirmation" rather than as an error. The parts are checked in order

1. Sender identity. The tenant's email sending credentials are held on the Email settings page, shown masked: the operator can verify that a credential is configured but can never read it back. Where mail broke immediately after someone "checked" the key by re-saving the form blank, the credential is sound and the cause lies elsewhere. Templates are fixed to the brand; the Email page manages only the sender credential. For franchise locations, the sending domain shall be authenticated: unauthenticated mail is filtered as spam: delivered from the Platform's perspective, invisible from the customer's.
2. Recipient data. Blank or malformed addresses fail in the data, not the system.
3. Consent. Messages to opted-out numbers fail by design; that is the compliance position protecting the Company, and overriding it is not an available correction. A channel the customer consented to is used instead.

Where one customer reports a missing notification while others receive theirs, the cause is their address, their spam folder, or their carrier: not the Platform. The operator verifies the send was attempted and accepted by the provider. Where it was, the trail ends at their inbox provider, and the customer is told the message was sent and accepted, to check spam, and how to allowlist the sender. Where it was not attempted, the operator works backward through the parts above until the sequence breaks.

The settings page shows defaults, or saves do not hold

Two distinct causes

1. Every settings screen shows clean defaults. The settings service has fallen back to the built-in defaults because it cannot reach the database. That is a connectivity signal, not a data loss. The operator checks the database connection before touching any setting; see System.
2. Saves appear to succeed but values revert. The operator checks the administrative change record for whether the write actually committed: every committed change through the settings path is recorded there, so a missing record means the write never landed. The stored-copy refresh is also remembered: runtime reads carry a 5-minute cycle, and a save followed by an immediate check that reads the old value is usually the refresh, not a failed write. The operator waits, re-reads, and then escalates with the change record as evidence.

Controls

• Diagnosis never proceeds by changing settings to see what happens. A value is changed only where the stored data shows it wrong, one change at a time, under the change authority in Settings and Booking Operations.
• No access record, location record, or settings value is deleted to resolve a symptom; deactivation and correction leave the record that explains the outcome, under Admin Users and Organization.
• A setting changed during diagnosis never overrides a governing legal document, and consent failures are never overridden for any reason.
• Credentials encountered during diagnosis: sender keys, processor keys, banking access: are verified as configured only. They are never read back, copied, shared, or recorded in an incident note or any other document.

Records created and where they are kept

Incident notes stating the symptom, the stored values found, the correction made, and the evidence relied on: together with the administrative change records the corrections produce: are kept with the tenant's administrative records and retained under the Regulatory Record Retention Policy.

Escalation

A problem that survives this runbook is escalated to support@aapawz.com with the stored values and change records as evidence, not with a summary of impressions. A substituted or unverified link, a suspected unauthorized settings change, or any legal process goes to legal@aapawz.com the same day.

Review cadence

The System Administrator reviews this runbook after every incident it is used for and quarterly in full, adding each new verified cause in the order it should be checked.