Admin and service ownership
Admin composes Account administration into one browser interface. Durable resources remain owned by the service responsible for their behavior.
Composition boundary
Admin owns the browser experience. It can manage authentication redirects, browser sessions, forms, navigation, and calls to published service APIs. Admin does not keep a second copy of Account, billing, licensing, or domain state.
| Resource | Owning service | Admin responsibility |
|---|---|---|
| Account profile | Account | Present Account settings |
| People | Account | Present human directory actions |
| Agents and installed apps | Account | Present non-human principals |
| Groups and memberships | Account | Present group and membership controls |
| Product licenses and seats | Licensing | Present effective access and seat assignment |
| Purchases, subscriptions, payment methods, credits, and invoices | Billing | Present commercial actions and records |
| Domains and DNS verification | Domain | Present ownership and verification actions |
Customer documentation
Admin documentation starts from a task that an Account administrator performs. A task can cross service boundaries when Admin presents it as one operation. For example, buying product access uses Billing to create the subscription and Licensing to expose the resulting access.
Developer documentation
Developer documentation starts from an API, resource model, authentication contract, or Cloud Project. Open Socra Cloud for Project-level service and OAuth configuration. Admin guides can link to developer material, but they do not duplicate service API reference.
This separation keeps customer procedures stable while each service evolves its own machine interface.