About the Admin Center

The Admin Center is the central workspace for configuring AlloyScan. It exposes two distinct administrative scopes through tabs in a single page, and it works in concert with a two-role permission model that determines what each administrator can change.

Admin Center

How the Admin Center is organized

The Admin Center page presents two tabs:

Site Settings — per-site configuration. Everything you change on this tab applies only to the current Site (the tenant identified by the slug in the URL). This includes Identity and Access Management (IAM), Settings (such as scan schedules, audit schedules, change tracking, snapshot storage), Customization (tags, tools, custom audit fields, custom software recognition), Tasks and services (Audit Services, Audit Agents, Active tasks), Notifications, Logs, and Limits and usage.
App Management — instance-global configuration. What you change here affects the whole AlloyScan instance: Sites, Site Template defaults, Global IAM, Notification templates, the Email client, Resources (Manufacturers), Billing / License Information, Multi-site reports, and global-scope Logs.

If your account is scoped to a single tab, you see only that tab. Most administrators see only Site Settings; a smaller group of operators see only App management; some advanced operators see both.

The two-role model

AlloyScan ships two built-in roles, and they are scoped at different layers:

Administrator — site-scoped. Full configuration authority within the Site they belong to. Administrators provision users, install Audit Services, define Segments, manage credentials, configure schedules, manage notification templates, run reports, manage customization items such as tools, tags, custom audit fields, and software recognition rules, and review per-site logs. Administrators cannot perform cross-site operations and cannot exceed their Site's quotas.
Global Administrator — instance-scoped. Operates on the App management tab. Creates and retires Sites, maintains the Site template that seeds new Sites, configures the instance Email client used by all Sites for notification delivery, manages the Manufacturer registry, uploads the license file, reviews aggregated Discovery quotas, and runs Multi-site reports. A Global Administrator does not bypass per-Site role-based access control — per-Site CRUD still flows through that Site's IAM.

A regular User role is read-oriented within a Site: it cannot reach App management at all and has limited presence on Site Settings.

Deployment settings shape what you see

Some deployments can hide entire menu items in the Admin Center, regardless of role:

Security log
Change log
SSO providers

If a menu entry is disabled for a deployment, it is not rendered for any user on that instance. When a menu item is missing, first confirm the user's role, then ask your deployment operator whether the surface is enabled for the instance.

Why this design

Splitting the Admin Center into Site Settings and App management lets a single instance host many isolated tenant Sites while keeping shared concerns (license, email transport, manufacturer normalization, multi-site reporting) under instance-wide control. The two-role model keeps day-to-day configuration close to the people who own the data — Site Administrators — while reserving fleet-wide changes for Global Administrators.

Key distinctions

Site Settings vs App management — site-scope versus instance-scope; tenant-isolated versus shared.
Administrator vs Global Administrator — the same word "Administrator" describes two different scopes; the qualifier matters.
Role versus deployment availability — RBAC governs who can act; deployment configuration governs whether the surface exists at all on the instance.

Limitations

Only two shipped roles (Administrator and User). There is no per-capability granular role-based access control and no scoped-admin variant within a Site.
Some Admin Center options remain visible even when the underlying capability has not been exercised end-to-end on every deployment; treat the menu entry as the canonical entry point and verify the workflow as part of your change.