The Atria Service Model
Overview
A service in Atria is a tangible deliverable that can be assigned to a Customer or a User within a Customer. These services are modeled to reflect the way a product is sold or delivered, providing flexibility and alignment with business processes.
Atria includes pre-built, ready-to-use service modules and additionally allows Service Providers to create custom service modules.
Service Properties
Each service in Atria has a set of properties that define its configuration and information required for fulfillment:
- Defaults and Configuration Settings: Includes patterns for naming conventions, default preference settings, etc.
- Information Capture: Used to capture essential data like instance name, license keys, owner name, and more.
- Inheritance and Overrides: Service properties are inherited through the customer hierarchy from the location where the service is enabled. These settings can be overridden at both Reseller and Customer level.
Service Types
Atria distinguishes between two primary service types: Customer-Only Services and User Services.
Customer-Only Services
- Definition: Services not directly tied to individual users.
- Pricing: Priced per instance.
- Provisioning: Can only be provisioned to Customers, not Users.
- Examples: Websites, databases, servers.
- Use Case: Typically used when services are billed per customer rather than per user.
User Services
- Definition: Services that can be assigned to both Customers and Users within those Customers.
- Pricing: Often sold at a per-user price.
- Provisioning: Automated processes provision each user with the service.
- User Details: Typically requires user-related information such as license keys or user details.
- Examples: Mailboxes, M365 subscriptions, virtual desktops.
- Association: Always associated with an end-user.
Multi-Instance Services
Services can be defined as "multi-instance," meaning they can be provisioned multiple times for each customer or user.
- Customer Service Example: A customer may need multiple databases.
- User Service Example: A user may have both test and production versions of an application.
Service Plans
Services in Atria come with plans that apply at both Customer and User levels. Plans allow predefined configuration, defaults or variables to be set when provisioning.
- Configuration and Variables: Plans can define storage limits, CPU performance, and other relevant service variables.
- Feature and Price Alignment: Plans ensure that service features align with specific price points, providing flexibility in offerings.
- Use Cases: Use plans to control variables such as storage, memory, feature enablement, and region/datacenter location.
Reseller Structure and Services
Services are delivered to customers via the Reseller hierarchy. Service properties and plan properties can be overridden at both the Reseller and Customer levels. User-related properties can also be overridden at the User level.
The ability to override default settings at various levels allows individual Reseller and Customer requirements to be handled easily, while avoiding any need for complex error-prone manual processes.
Example Uses:
- Allow a Reseller to rename a service and service plans to align with their own brand.
- Adjust product SKUs stored against plans to cater for exceptions in billing.
- Change defaults for a Reseller's customers.
- Isolate storage or infrastructure for a Reseller's Customers or a specific Customer
- Adapt to naming conventions previously used, simplifying import processes.
- Customize plans to meet specific market needs, such as varying storage levels.
Learn more within Channel Support.
Automation - Service Provisioning
A key part of the Atria service model is its support for automated provisioning. Provisioning occurs when a service is assigned to a Customer or a User. Learn more about Provisioning Concepts in Atria.
Service provisioning events occur for:
- Provisioning service to a customer.
- Provisioning service to a user.
- De-provisioning service from a customer.
- De-provisioning service from a user.
Each provisioning request contains the context of:
- the service, any selected plans and any user entered data.
- the object it's being applied to (for example a Customer or User).
The Provisioning Request is transmitted in Message Form. It is self-contained and is routed to the appropriate Provisioning Engine for the current Customer. The next page explains the concepts around Provisioning in more detail.