Admin guide
Manage accounts, users, and controls
Administrative setup should keep access tight, auditable, and aligned to the real operating structure.
Core admin areas
- Account settings define tenant-level behaviour and product controls.
- Client management defines customers, portfolios, customer groups, or landlord groups under the account.
- Site / Property management defines physical facilities, properties, addresses, estates, or operational sites under a client.
- Users should be assigned roles that match their operational responsibilities.
- Client and site access should be kept as narrow as practical for each user.
- Platform settings are reserved for platform administrators.
Account, Client, Site, and Location hierarchy
Graicx uses a consistent hierarchy for administration, reporting, permissions, and analytics: Platform to Account to Client to Site to Location.
- Account is the tenant, service provider, property manager, or business owner in Graicx.
- Client is the customer, portfolio, customer group, housing association, landlord group, or owner group under an account.
- Site / Property is the physical facility, property, address, estate, or operational site under a client.
- Location is the sub-site structure such as building, entrance, floor, apartment, unit, room, or area.
- For simple deployments, account, client, and site names may be similar. The system still keeps separate records, IDs, and parent relationships.
Access model
Graicx separates platform administration from account administration and operational user access. Account administrators manage their own account context, while regular users only see records within their assigned scope.
- Platform users can administer across accounts.
- Account administrators can manage users and access within their own account.
- Client access grants access to the sites under that client.
- Site access grants access to specific selected sites.
- Location, asset, and operational records inherit their parent site context.
Roles and permissions
Each user has one role, which sets what they can manage. Admins can additionally be scoped to specific clients. Workflow policies and rules can be set at platform, account, client, or site level, and each level inherits from the level above unless an override is set.
| Role | Scope | Workflow policies / rules | AI settings |
|---|---|---|---|
| Platform admin | All accounts, clients, sites | Manage all scopes, including platform defaults | Manage platform / account AI governance |
| Full account admin | Own account | Manage account and its clients and sites | Manage Analytics chat only; view everything else |
| Client-restricted admin | Assigned client(s) | Manage assigned clients and their sites | No write access |
| Site manager | Assigned site(s) | Manage assigned site policies | No access |
| Operator | Operational data in scope | None | None |
| Technician | Assigned work | None | None |
| Read-only | Read within granted scope | None (read only) | None |
Full account vs. client-restricted admins
An account admin can be left account-wide or narrowed to specific clients. The distinction is set entirely by whether any clients are assigned.
- Full account admin: no grants assigned. Manages all settings and workflow policies for the account, plus every client and site under it.
- Client-restricted admin: one or more clients assigned. Manages workflow policies for those clients and the sites under them only — not account-level policy, other clients, or other sites.
- Site-scoped admin: one or more sites assigned (no client). Manages those sites only — site settings, IoT, and site-scoped workflow policy — not the account or other sites. (Replaces the former Site Manager role.)
Assigning a client-restricted admin
Client and site administration
- Clients are first-class records in the admin experience.
- Every site is created under a parent client.
- The account relationship for a site is derived from its parent client.
- Client detail pages show related sites to make the Account to Client to Site structure visible.
Workflow settings
Workflow settings control how service requests are processed and what automated actions occur during the pipeline.
- Policies define how service requests are processed at each scope. Settings include duplicate detection, AI triage, work order creation, and Smart Assignment. Policies are inherited from platform to account to client to site.
- Rules automate responses to pipeline events. A rule fires when its trigger is matched and its conditions are met, then sends an email notification or routes the request to review.
- Templates define the content of workflow email notifications and must be connected to a rule before they are sent.
AI administration
AI controls give administrators visibility into how AI analytics is used and provide account-level controls for availability, cost, and tool access.
- The AI usage dashboard shows monthly spend, request counts, token usage, failed or blocked requests, and average request duration.
- Breakdowns are available by model, feature, error type, and request outcome.
- AI settings include AI enabled, analytics chat enabled, PII allowed, preferred model, data retention mode, and allowed tool categories. Closeout Assist and Document Analysis are managed under Workflow Policies, not here.
- Budget controls include monthly budget, warning threshold, hard limit, current monthly spend, and reset timing.
- Allowed tool categories let administrators control which AI tool groups are available for an account.
AI admin access
- Platform administrators can manage all AI settings and budgets across accounts.
- Full account administrators can manage Analytics chat availability for their own account and view all other AI usage and settings. The AI master switch, PII, preferred model, data retention, tool categories and budgets stay platform-managed.
- Client-restricted administrators and site managers cannot change AI settings.
- Regular users cannot access AI administration controls.
Admin safety