Organization

This standard governs the organization record of All About Pawz, LLC: the single tenant record the whole Platform reads to know who the business is: together with its brand fields, its locations, and its operating hours. The storefront header, booking confirmations, receipts, transactional email, and franchise portals all take brand, contact, and legal identity from this one record; there is no second copy. Where a surface displays the wrong business name or telephone number, the correction is made here, not in the surface that displayed it. The Organization Administrator maintains this record; only a holder of the administration grant at the highest level, or an owner, may change the legal identity, domain, or currency fields, under Admin Users. No setting in this record overrides a governing legal document: where this record and a signed agreement, a filing, or a policy in §2 of this library differ, the legal document governs and this record is corrected to match it.

The tenant record

The record carries three kinds of fields

1. Identity: the display name customers see, and the slug: the human-readable identifier referenced across the Platform. The slug is treated as permanent; changing it breaks references in places nobody will think to check, and it is changed only by an owner, with the consequences recorded.
2. Legal: the legal name, the doing-business-as name, and the tax identifier. These fields flow into invoices, receipts, payout tax documents, and franchise agreements. The display name is not a substitute for the registered entity name on a tax form or a franchise agreement.
3. Contact: the support email, support telephone number, and website address presented to customers. The only email addresses presented as ways to reach the Company are support@aapawz.com for operational matters and legal@aapawz.com for legal notices; no other address is entered as a Company contact point.

The legal procedure is

1. Enter the legal name exactly as it appears on the state registration, and complete the legal fields before they are needed: they are needed at the worst times.
2. When any identity fact changes in the real world: a rebrand, an entity change, a new tax identifier: update this record in the same week, then verify the places it flows to: produce a test invoice, check the payment processor's business profile, and confirm a transactional email footer.

Domains. Two fields do different jobs. The primary domain is the domain the Platform treats as home: the links the Platform publishes as its own, its search identity, and its site map are built from it. The custom domain points the business's own branded domain at the Platform. The primary domain is changed only during a quiet period, and the search indexing is re-verified afterward; every published link and every absolute link in email already sent shifts with the change.

Currency. The default currency, United States dollars, is the currency of record: every price, payout, and report is stated in it. Changing it on a live business is a migration, not a switch: historical data does not convert itself: and it is not done by an operator.

Presentation preferences. A small set of presentation preferences: a geographic suffix, a price-range indicator, display limits: changes presentation, not data. The operator reads the current value before changing any of them.

Processor linkage. The tenant record also carries the Platform-level processor account linkage, separate from the per-settings processor keys in Settings. Where payouts misbehave, this record and the processor's own console are the two places to check; see Payments (Accounting Payments).

Brand and identity

The logo, the dark-mode logo, the favicon, the primary, secondary, and accent colours, the brand font, and the social links in this record are the single source for how the business looks on every surface: storefront header, customer portal, email templates, receipts, and the franchisee portals that inherit the brand.

1. Logos are entered as addresses of hosted images the Company controls. If the hosted image becomes unavailable, every surface referring to it breaks at once; there is no local fallback.
2. The dark-mode logo keeps the mark legible on dark headers and in email clients that invert backgrounds. Where it is absent, the standard logo is used everywhere, washed out in dark contexts.
3. Colours are entered as hexadecimal values. The primary colour drives buttons and key actions, the secondary supports, and the accent is used for highlights and badges. A change made here propagates, but not instantly everywhere: stored storefront pages and email already sent keep the old values. A rebrand has a transition period, and yesterday's email showing yesterday's colour is not a defect.
4. Social links are the business's social profiles, rendered in footers and on the contact page. A link to a profile that no longer exists is worse than no link; the Organization Administrator keeps them current.

Locations

The Platform keeps two location systems, and the operator shall know which one a given screen reads before changing either.

The current system holds the live locations: for the Company, its main location, in the America/Chicago time zone, marked primary and active. The administrative Locations screen reads and writes this system, and the tenant switcher in the administrative sidebar reads from it. Franchise signup, under Franchise Signup, creates a location row in this system for a new shop's primary physical location. Each row carries a name, a structured address: street lines, city, state, postal code, telephone, email: a time zone, a primary marker, and an active marker.

1. Only one location is ever primary. The primary location is the default wherever one location is required: tax jurisdiction defaults, the return address on shipping labels, and the fallback where nothing more specific is set. Two primaries mean downstream handling guesses, and guessing produces intermittent wrong-address faults that take weeks to notice.
2. Older rows may hold the address as a single line of text rather than the structured form; the screens accommodate both, and operators do not rewrite old rows by hand for tidiness.

The older system holds earlier location rows: including near-duplicate rows for the same premises, differing only by a dash character in the name. This is recorded duplication, not a mystery: the administrative Locations screen, the tenant switcher, employee time records, and franchise signup read the current system, while one settings component still refers to the older table. Until that reference is retired, both sets exist and both can appear in different pickers. The procedure is

1. Do not delete the older rows yet. Something still reads them; deleting first and discovering what second is how outages happen.
2. Merge or deactivate the near-duplicate main-location rows. Two rows that differ by a dash character will eventually diverge: one receives the new telephone number, the other does not: and then there are two sources of truth. Deactivate, rather than delete, the row that loses, so the history remains auditable.
3. Add every real new premises in the current system, through the Locations screen. That is the system the current procedures read.

Time zone discipline. Every slot a customer sees, every "today" in every report, and every cutoff calculation resolves in the location's time zone. America/Chicago is set on the first day for any new row. A wrong time zone produces no error; it produces appointments off by an hour, which customers experience as the business being unreliable.

Operating hours

Operating hours are kept one row per location per day, and the booking engine enforces them as binding: no slots are offered outside them. Holiday and one-off closures are kept as blackout records, which the system also applies to availability. Booking rules that sit alongside hours are governed by Booking Operations.

Both are managed from the Operating Hours & Holidays screen, which also exposes the online-booking switch: the exact setting the public booking path checks. Where online booking is unexpectedly off, that switch is checked before anything else.

1. Never delete an hours row for a closed day; mark the day closed. A missing row is ambiguous: closed, or data missing: and different parts of the Platform resolve the ambiguity differently. An explicit closed marker is unambiguous everywhere.
2. The Platform does not move existing appointments when hours change. After any hours change, the operator takes the upcoming appointments for the affected days and handles the exceptions personally. A personal call costs less goodwill than an automated cancellation.
3. Enter blackouts the moment they are decided: Thanksgiving, Christmas, staff training. Online booking reads them as they are entered, so a customer booking in October for late December correctly sees the closure where it has been entered. Where it has not, the customer books a slot the business must then cancel, and a cancellation the business initiates always costs more goodwill than a slot never offered.

Adding a location: the sequence

1. Create the location. In the Locations screen, add the new location: name, address, time zone, and the tenant it belongs to. Leave the primary marker off unless this location replaces the current primary.
2. Set the hours. Add the weekly schedule in Operating Hours & Holidays: every day, including closed days marked closed. A location with no hours rows is effectively closed every day as far as the booking engine is concerned; that is the most common cause of "the location was added but nobody can book."
3. Enter blackouts for any known closures.
4. Confirm capabilities. Where the location fulfils orders, confirm it is the location the fulfilment handling expects. Where customers book grooming there, confirm it appears among the bookable locations.
5. Verify. Book a test appointment, confirm it lands in the right staff calendars, and check the address on a test order. Then tell the team the location is live.

Where something goes wrong mid-sequence: hours attached to the wrong location, a typing error in the address: the operator updates the rows in place. Locations are not deleted and recreated: deletions cascade in ways that are hard to audit, while updates leave a clear record.

Controls

• Who may change what. Legal identity, tax identifier, domains, and currency: an owner, or an administrator holding the administration grant at the highest level. Brand fields, contact fields, and presentation preferences: the Organization Administrator. Locations and hours: the Organization Administrator and location managers for their own location. Every change is attributable to the person who made it.
• A setting in this record never overrides a governing legal document: a franchise agreement, a filing, the Terms of Use, or any policy in §2. Where a value here conflicts with such a document, the document governs and the record is corrected.
• The slug, the primary domain, and the currency are treated as structural: they are changed rarely, deliberately, and with the downstream verification this standard states.
• Banking and processor credentials are never entered in this record and never recorded in any document; processor linkage here is an account reference, not a credential.

Records created and where they are kept

Changes to the tenant record, location rows and their deactivations, hours and blackout records, and the verification results this standard requires are kept in the Platform's administrative records, with the change history the Platform records for administrative actions. Organization records are retained under the Regulatory Record Retention Policy.

Escalation

A conflict between this record and a legal document, a domain or identity change with legal effect, or service of process addressed to the Company goes to legal@aapawz.com on the day it arises. Operational problems: a location that will not appear, hours that will not apply: go to support@aapawz.com, after the checks in Troubleshooting (Organization Settings Troubleshooting).

Review cadence

The Organization Administrator reviews the full record quarterly: legal fields, domains, brand fields, social links, locations, and hours: verifies the registered identity against the state registration annually, and reviews this standard whenever the Platform's location or booking handling changes.