Atria Studio
Software Development Kit
Atria provides its SDK development kit to its clients in order to allow them to enhance and connect multiple applications to work with the Atria platform.

Atria SDK
Introduction
The Atria Platform enables MSPs to deliver fully automated services to customers and end-users. Out of the box, Atria supports many commonly delivered Microsoft technologies, and allow customer self-service and administrator free administration for your support team.
Every MSP has a preferred tech stack that makes up the products and services they deliver to their customers.The Atria SDK allows MSPs to productise and build offerings, and then provide simple and fast delegated administration to your end-customers and service desk.
Benefits include
- Standardisation of Support Processes across all technologies
- Provide Self-service across all services to enable a true “as-a-service” experience to customers.
- Reduce requirement for engineering/technical skills for day to day operations
- Remove risk of error by standardising and automating core processes
- Standardise and automate Service billing
- Enable self-supporting reseller channels
The Atria Service Model
Service Fundamentals
Services are sold to customers, a Service schema in Atria defines the attributes of a service, how it is sold and the automation that needs to be executed when it is Provisioned.
Provisioning is the process of assigning a service, it may or may not include technical automation, but when completed, a billable event has occurred.
Services must be assigned to Customers, and depending on their design, can also be provisioned to Users.
A Customer Only Service can only be provisioned to a customer -it is not directly associated with any user.An example would be, a database, a website, a server, a network, a router etc.
A User service must also be provisioned to a User.An example would be, a mailbox, a license for an application, a desktop, a VOIP connection.
Service Instancing determines how many times a service can be provisioned to a customer or user.A single instance service is Boolean – it’s either on or off for that customer/user. A multi-instance service may mean that multiple instances of the service can be provisioned.
An example of a single instance service is an Exchange mailbox – only one can exist for a customer.
An example of a multi-instance service is a CRM system, a development, staging and production instance may be required.
There are many permutations of service that can be catered for within the Atria service structure, the core benefit is that you can model virtually anything quickly and in most cases without writing any code.
An example of a single instance service is an Exchange mailbox – only one can exist for a customer.
An example of a multi-instance service is a CRM system, a development, staging and production instance may be required.
There are many permutations of service that can be catered for within the Atria service structure, the core benefit is that you can model virtually anything quickly and in most cases without writing any code.
Service Plans
Atria Service Plans provide Product Options within Atria. A service plan can be assigned a SKU which can then be translated directly into a billable item.
When designing services, service plans can apply at both customer and user level.
Each service plan can have any number of Properties defined. Each property can contain user editable information (i.e. parameters that are supplied at time of provisioning), or defined configuration which is only editable by Atria administrators – the configuration which makes one plan differ from another.
For example, an Backup Service could have multiple attributes – we would define these as plan properties.
Property | Purpose | Type |
Bandwidth | Monthly bandwidth Allowance | Service Provider Configuration |
Support Level | Level of Support included | Service Provider Configuration |
Storage | Amount of Storage included | Service Provider Configuration |
Once the schema is configured, you can then define as many plans asyou like – these are created in the system, and are then used when you provision the service to the customer.
Example Plans For our hypothetical Backup Service
- Backup Standard
- Bandwidth : 100 GB
- Support Level : Business Hours, email only
- Storage : 1 TB
- SKU : BU001
Backup Extra
- Bandwidth : 1 TB
- Support Level : Business Hours, email only
- Storage : 10 TB
- SKU : BU010
Backup Premium
- Bandwidth : Unlimited
- Support Level : 24×7 phone and email
- Storage : 20 TB
- SKU : IA003
Well designed plans ensure that:
-
- Your marketing messages and price points translate into the services you provision
- It’s easy for services to be provisioned to customers and the right information is always passed.
- The parameters included in the plan are instantly available for your automation.
When designing plans, Atria allows you to define validation controls which ensure data integrity, out of the box you can create drop down lists, apply regular expressions, or define data types.
Overriding Attributes
By default you will not need to change plan configuration, but if needed, you can go in and override the plan settings on a customer by customer, or reseller basis.
In our example, imagine that a VIP customer has threatened to leave, they have a competing offer which has more included storage.To keep the customer buying your service, you can just go in and override the storage setting for that one customer. All provisioning stays the same, you don’t need to create a special plan and simplicity is maintained.
Customer and User Service Properties
Aside from plans, Properties can be assigned to the Service at both the customer and the user level.
Properties can be used to:
-
- Store configuration settings needed for provisioning
- Capture and store instance specific data needed for provisioning
- Store information which has been created as a result of provisioning
Properties defined at the Service level are available across all resellers and customers,
Properties defined at the Reseller level are available within that reseller and sub-customers
Properties defined at the Customer level are captured and available within that customer
Properties defined at the User level are captured and available at the user level
Where the property is configured determines it’s scope and where it can be changed.In most cases, properties can be overridden down the hierarchy.i.e. a service level setting, could be overridden for a particular reseller or customer.
In our Backup Service example, At the service level, we have the one off config needed for our provisioning process, and at a Customer level, we need to capture more information at provisioning time.
Property | Property Location | Purpose | Type |
BackupURI | Service | Defines API to use to access Backup System | Hidden config |
APITokenSecret | Service | Defines the name of the secret to be retrieve for accessing the API | Hidden config |
Username | Customer | Username for connecting to service | Text with REGEX |
AdminEmailAddress | Customer | Email address for backup related emails | Text with REGEX |
Contract Duration | Customer | Years of contract | Drop Down list |
Now, when it comes to provisioning, the service desk or even the customer, is able to pick a plan and then enter the required details. This then sends off the provisioning request to complete the process.
Storage of Secrets
When integrating systems, there is often a need for secrets to be stored. Usually, the secret is for accessing an API – it could be a token or a password. Atria components have access to a secret store – this can be accessed via PowerShell. Secrets are encrypted then stored.
In our example above, the property for the APITokenSecret would supply the name of the secret to be retrieved. As part of the provisioning process, the secret can be easily retrieved and used without needing to expose the secret to any user.
Provisioning Logic
We have so far discussed how Atria can capture service requests in a standardised and simple format.
The outcome of all Provisioning is a provisioning request, In message form, this contains all of the information needed to complete a provisioning process. The message is passed to a queue and routed to a provisioning engine.
Each provisioning request packages all the information you might need to perform the provisioning task.
The request is a simple data structure – it includes
- Customer level details – e.g. the Customer Entity in Atria
- User level details – if applicable (i.e. a user level service), all of the user details are also contained within the request.
- All the Service properties at all levels, and with any overridden settings applied
- The selected Plan and plan properties
As a cooking metaphor,
Ingredients = Request
Recipe = Provisioning Process
Each Provisioning rule is a step in the recipe that uses ingredients
Provisioning Process
Provisioning occurs in three parts:
- Pre-Provisioning – where the request can be further enriched with data
- Provisioning – where the provisioning is actioned
- Post-Provisioning – where results from the provisioning can be stored
Due to the distributed nature and depending on how Atria is configured, Provisioning may take place in a different network or system, Pre and Post provisioning usually occur within the main Atria platform.
Each provisioning process is made up of a set of provisioning rules, each rule defines a provisioning action to run and a condition which determines whether or not it should run.
Provisioning actions are the building blocks of provisioning processes.
Provisioning Rules are soft – they are defined in the database and compiled into a program when the provisioning engine starts.This means that compiled performance is gained, but the flexibility to change, adapt and enhance is maintained.
Provisioning Actions
Atria contains 100+ action libraries. Each actions performs a single task.
Each action has a defined set of input parameters, A provisioning rule feeds values into the parameters from the provisioning request parameters.
Example Actions include:
- DNS – Create A Record
- Exchange – Create Mailbox
- Active Directory – Create Group
PowerShell Actions
If you use Powershell, Atria has multiple powershell actions – these will create a PowerShell session with variables prepared and ready for use in your script.
For executing Powershell against Microsoft 365, Atria handles connecting securely using the Secure App Model.
Custom Actions
It is also possible to create custom Actions using .NET. You can use this to encapsulate any complexity and provide a simple interface for other Atria customers or operations teams to use.
For example, a Create Backup Account action, could take the parameters from our imaginary Backup Service, and setup the required storage and account for the new customer.
Provisioning Manager
The provisioning manager is a simple windows utility that is used to view, build and debug provisioning processes.
Tracing from provisioning requests allows you to pinpoint problems and diagnose where your provisioning processes are failing, rules can be disabled, added or removed.
Provisioning Events
Within core provisioning processes, before and after placeholders exist.These allow customization of existing services.So for example, if you wanted to perform additional processing after a default out of the box Atria service.You can add your logic and this will be maintained across upgrades.
Batch Processing
When integrating systems, it is often the case that recurring scheduled tasks are needed to keep systems in sync, to perform maintenance tasks, or to perform processes such as billing or email notifications.
Atria has an inbuilt scheduling system which can be used to execute any process.
Scheduling
Any number of Jobs can be setup with differing schedules.Like Windows task manager, the last run and next run date are shown.
Standardized Logging
An easy to use five level logging system is available and can be used by custom Job Runners (C# code) or can be used through the standard PowerShell Job Runner.
This means that your senior engineers can standardise batch processing and logging across systems and provide error code specific direction to more junior engineers to resolve issues.
Building custom pages
Provisioned Services may require associated administrative functions.
As an example, our Microsoft Online service procures and provisions Microsoft licenses to users. Alongside this Atria also provided delegated admin features for managing Azure AD Groups, Resource Mailboxes, Shared Mailboxes and Exchange Online Contacts.
Through the SDK, you can build pages and publish them out to your users, this means they can self-serve rather than call your helpdesk.
In our Backup Example, a custom page may be able to link through to the backup console for the customer, or show the storage being consumed.
Permissions
Each service added comes with a set of default roles, the roles define the permissions needed for the different functions.
As an example
The Service Provider and Reseller is able to provision or deprovision the service to or from a customer
A customer is able to provision or deprovision the service to or from a user.
Within Atria, you can further define customised roles for your internal teams. For example, L1 helpdesk, you may want to revoke the ability to remove the service, but it might be fine for them to assign the service.
Permissions can be applied to Pages, Menus, and Service provisioning, you can also add your own permissions to use within your code.
Notifications Engine
Services by default have notification events, these can send internal or external emails on completion of provisioning.
In our Backup Service example, on completion of provisioning a notification event is raised. A notification can be defined which is sent out to a user containing all the information they need to get connected to their new backup service.
Variables from the provisioning request can be placed into the notification, it can also contain attachments and even be sent out in different languages.
Importing and Exporting Service Modules
Service packages, allowing you to move services in and out of an Atria instance.
Each service has a Service Schema – the import/export feature allows you to transfer services between Atria systems.
The Service Schema contains
- The Service definition – properties, plans and structure
- The provisioning rules for the service
- Any notifications defined for the service
- Roles and Permissions associated with the service
- Any DLLs or files needed for UI or provisioning