Onboarding for MSPs in BMC Helix Service Management multitenant environment

In the following sections, you will learn about the onboarding process for MSPs and the multitenant model, where a single instance serves multiple customers or tenants.

To understand the onboarding flow, see the following graphic, which lists the tasks that BMC would handle and the ones that you must perform.

Onboarding diagram.png

Day 0: Plan and prepare

Planning and preparation activities refer to actions to initiate your BMC Helix activation. Ensure that the right point-of-contacts are added to receive important BMC communication and optimize your ramp-up period.

The different steps that are carried out in this phase are:

First, BMC finalizes and sends the order form to your (i.e., MSP) Technical Contact. Both you and BMC sign this order form.
Your Technical Contact then receives an order confirmation email with a link to the registration portal. Your Technical Contact fills out pertinent details, BMC initiates the activation for the BMC Helix instance.
Update technical and maintenance contacts using the Contact List.
Raise requests for any additional services or requirements in the Support Central portal. To learn more, see Request-process-for-BMC-dependent-activities.
BMC performs the following steps to activate the BMC Helix environment:
1. Activates systems and required services.
2. Activates the following environments with the latest versions of BMC Helix ITSM and the BMC Helix applications.
  - Development (with Admin access)
  - QA
  - Production
  - Any additional environments purchased in your subscription
3. Configures one inbound and one outbound email server for each environment. After the activation, BMC sends an email with the environment and access details for the services you have opted for.
4. Configures distinct and separate accounts for each target environment—development, QA, and Production—on the BMC-hosted SFTP servers.

For detailed information about the onboarding process, see Onboarding to a new BMC Helix Innovation Suite Cloud.

Day 1: Configure the BMC Helix environment

You must perform the following tasks to perform the initial configurations for the BMC Helix environment. These settings are available in the Application Administration Console for manual configuration.

Create Foundation Data

Setting	Best practices
Create company structure	Start by creating a company that will be used as the parent of all other companies. MSP Admins must create a company via the Application Administration Console or onboard it automatically via a pipeline. The company would be created in the COM:Company form. For more information, see Creating companies. The company type must be set to Service Provider for the MSP company. This action automatically creates a group in the AR System tied to this company. It makes the group available to be associated with other data in the system driven by the MSP company.
Define the support group structure to support MSP Agents	If MSP agents work on tickets on behalf of the tenant, and the MSP's support group must be the group to which the ticket is routed, you must create support groups based on the function the group will perform and associate them with the MSP company. Support groups can be created via the Support group definition step in the Application Administration Console. For more information, see Creating support groups.
Create locations	Create any needed locations to support the MSP company and agents. The locations must be associated with the MSP company. You must also create sites, as a location is a site's connection to a company. Locations can be created via the Application Administration console. For more information, see To add a company location.
Define global product and operational categories	The product and operational categories must be created globally across all tenants. A limitation with global categories is that MSP admins cannot disable them for just one company. They are either accessible to all companies or none. So, because of this limitation, you must decide whether to support global categorizations.
Set global rules	Several global rules need to be set. Because all companies use these rules, you must determine how they want the system configured. Two Row-Level access model models are supported. One provides access to incidents based on the support group assigned to the ticket and who has submitted the ticket. The other model is to drive access based on both the company and the support group. This model is configured via the system rules in BMC Helix ITSM. The most used model is the support group-only model for tickets, but it would need to be one that all customers will use. You can configure some settings as global settings or according to the specific requirements of a specific customer company. For incidents, these include defining which dates can be changed, if a service request should be created, what assignment process to use, if a service CI should be required, etc. You must review the rules, determine the global settings, and manage setting and changing any of these rules. Navigate to the Advanced Configuration for each product and configure the rules in the rules form. Change Rules Incident Rules Problem Management Rules Release Management Rules
Priority and urgency	Priority configuration is based on impact and urgency and can be configured per company. However, you must manage the administration and not the tenant. As the data in the form is not protected, tenant admins can see data for other companies. You can also set priority ranges and other configurations for priority per company. However, you must manage them, not the tenant, as the forms allow the admin to see all the data.
MSP Agent configuration	The MSP company's agents and managers must be added to the system and configured with the correct companies, support groups, locations, etc.

Set up mailboxes and BMC Helix Single Sign-On

Setting	Best practices
Email and Notifications	In the NTE:Config-EmailMailbox form, you must configure mailboxes per company. Notifications can be sent to different mailboxes based on the company associated with the ticket.
BMC Helix Single Sign-On and URL Endpoints	For more information, see Request-process-for-BMC-dependent-activities.

Configure BMC Helix applications

Set up BMC Helix Digital Workplace

You must provide a common catalog that all tenants can use. Also, create sub-catalogs for specific tenants and give members of that tenant access to create catalog entries specific to their company.

For more information, see Assigning subcatalog roles to user accounts.

For customers who are subscribed to BMC Helix Digital Workplace, create subtenants by creating a record instance from the BMC Helix Innovation Studio UI.

To learn more, see Creating subtenants from a record instance.

Configure CMDB

The CMDB administration is not separated by company. As a result, your CMDB administrator would need to set up and make any necessary changes to the CMDB. We recommend using these best practices to make it easier to maintain the system.

Settings	Best Practice
Common reconciliation rules	For each class, define the generic rules that describe the precedence when data is merged from the import data set into the production dataset. You must also configure common rules to decide when purge or archive is done for data in the CMDB.
Product catalog	You must define a common product catalog for normalization purposes. The normalization engine cannot use different product catalogs on a per-company basis.

Configure BMC Helix Business Workflows

BMC Helix Business Workflows uses lines of business to segregate data.

If one of your tenants uses BMC Helix Business Workflows, you must configure a line of business for each company. To learn how to configure BMC Helix Business Workflows for the MSP model, see BMC Helix Business Workflows for a line of business.

Configure BMC Helix Dashboards

BMC Helix Dashboards supports the ability to have dashboards segregated by organizations that are synced from companies in BMC Helix ITSM.

To learn how to set up BMC Helix Dashboards to use organizations to segregate data, see Managing multiple companies in BMC Helix Dashboards.

Configure branding

For each customer, you must configure the aspects of the application so that it has different branding on a per-company basis.

For BMC Helix Digital Workplace, configure aspects of the end-user console on a sub-tenant basis. To see how to rebrand BMC Helix Digital Workplace, see Rebranding BMC Helix Digital Workplace.

For Progressive Web Apps, branding can be done globally. To learn how rebranding can be done in BMC Helix ITSM, see Rebranding BMC Helix ITSM on the Universal Client.

Perform the BMC Helix configurations

Define archive and audit rules

You must define a common set of archive and audit rules for the environment, as the rules cannot be defined per tenant.

To learn more about archiving in BMC Helix ITSM, see BMC Helix ITSM data archiving.

Define service level agreements

Determine if tenants can have custom service level agreements (SLA). You must be the administrator for any service targets and not the tenants. Allowing SLM Administrator access to tenants will allow them to view and update other tenants' service targets, so do not allow any admin access to the tenants.

Set up integrations

For integrations, the accounts used must be limited to access only to the tenants' accounts; otherwise, the integration might be able to access data from another customer. You must also control the creation of these integration accounts for each tenant.

Integration cannot be done directly to the database, as that would bypass permissions and row-level security. The best route would be to use published APIs or iPaaS to integrate with BMC Helix ITSM. Each tenant must have service accounts with the appropriate permissions for that integration to perform the required operations.

Configure global settings in your multitenant environment

You must configure the BMC Helix environment for your tenants, as tenant administrators cannot perform configurations for all necessary capabilities. These settings include:

Application-specific rules (for example, incident, problem, change, asset, etc.)
Approval mappings
Assignment mappings
Incident templates (authoring): This setting is controlled by the mapping to the support group.
Creating sites and locations: You must create sites and locations and manage this mapping for a tenant. This action cannot be done by a tenant, as sites of other tenants will be visible.
Only limited members of your team can have unrestricted access permission.
Tenant company members will not be able to create their integration via the Atrium Integrator client as it will expose other integrations that they are not supposed to view or access.
We recommend that you configure audit and archive rules for all tenants. Employees of the tenants' organizations must not perform these operations.
Define the service targets and contracts in Service Level Management on behalf of the tenants. Tenants must not define service targets as they can see targets created for other tenants, and they could create a service target that is exposed to others.
For any changes to names, support group names, or categorizations for a specific tenant, BMC Helix ITSM has a tool called DataWizard to update data across the application, as some of that data is denormalized for performance reasons. Access to DataWizard is not supported on a company basis, so you must perform any necessary updates.

Load Foundation data for tenants

BMC Helix ITSM provides enables administrators to load Foundation data into staging forms via spreadsheets or APIs. This data can then be validated and loaded into the appropriate forms in the BMC Helix ITSM Foundation.

When this functionality is used to load tenant data into the system, the data must be loaded and attached to the appropriate company. Two roles in ITSM drive access to importing data when using the Data Management spreadsheets: the DMT Administrator and DMT User roles.

To learn about the overall data load process, see Overview of the data load process.

To enable tenants to load their Foundation data, the MSP administrators must create the company data for the new tenant and then create users performing the data loads. The users must be given DMT Admin or DMT User roles and be associated with their company. This step allows these users to access Data Management and the templates and jobs associated with their company. The tenants can then use the spreadsheets to define the foundational data for their company and use the data management tool to load the data.

Access is enforced at the job level, so only those with the required access can see and update jobs. However, when the job runs, it runs with administrator permissions when it loads the data into the staging forms and performs the validation before loading it into the actual forms.

Day n: Onboard tenants

After configuring your BMC Helix multitenant environment, as an MSP admin, perform the necessary configurations on your tenant's behalf. This action is necessary because some configuration areas in the product do not allow the tenant administrator to change data.

Onboard your first tenant

Use the following best practices to perform the following configurations to onboard the first tenant. After this, you can onboard subsequent tenants in an existing multitenant environment without affecting the live tenants.

Setting	Best practice
Create company structure	You must create a company for the tenant as a child of the MSP company. This will allow for hierarchal row-level access so that an MSP agent can see all the data across all the customer companies, but the tenant will only be able to see data from their company and support groups. This is done via the hierarchal group configuration in the ITSM Application configuration console. The tenant must create support companies that are children of their parent company. This can allow for further data segregation within the tenant's company structure.
Configure Foundation Data	Configure Foundation data via the BMC Helix ITSM Application Administration Console. Bulk load of data into BMC Helix ITSM Foundation forms is also possible by using Data Management. Finally, AR System REST APIs or Java APIs can also be used to create data in the appropriate forms to configure data in BMC Helix ITSM.
Define support group structure	Create support groups for the customer under the appropriate tenant company or support company for the customer. Sometimes, you might need to create a hierarchy of support groups.
Define customer-specific product and operational categorization	Configure any tenant-specific product and operational categories. The tenant administrator cannot do this on their own as this area of the product would allow them to see data from other tenants. Configure this setting via the Application Administration Console, Data Management, or APIs.
Define customer-specific approval and assignment rules	As an MSP Admin, configure rules for assigning tickets and rules around how changes and other objects get approved. The Tenant administrator cannot perform this configuration, as the configuration forms do not segregate data by company. So, you must gather the required information from the tenant to configure the appropriate rules via the Application Administration Console or via APIs.
Define service Level Agreements	As an MSP, define any service level agreements that the tenant wants. The agreements must be defined so that they only run for the appropriate company. Otherwise, the service level agreements could become visible to other tenants.
Onboard agents	As an MSP, you must onboard the agents for the tenant into the system. The most common way of doing this is by using the data load functionality in BMC Helix ITSM. The agents will need to get added to the appropriate companies and support groups for their company. Also, do not grant unrestricted access to anyone from the tenant side, as that would give them access to all data in the system.
Configure change risk factors	The tenant can configure the change risk factors configuration via the Application Administrator Console under the Change Management configuration. Here, the tenant can be given access to configure the risk factors used in the risk calculation
Set up CMDB	Datasets are used in the CMDB to segregate data from different sources. Each tenant must have their import datasets for their integrations. As an MSP admin, you must configure these for the tenant, as row-level security does not protect the configuration. As an MSP admin, you must create datasets specific to the integrations the customer will use via the CMDB console, or the CMDB API. Otherwise, the rest of the CMDB settings will be global. If a tenant is using ADDM to integrate BMC Discovery into ITSM, the ADDM CMDB Sync job will need to run as an account specific for that customer company. Also, the integration will need to set the company on the CIs created appropriately based on the customer company and push the data to the correct dataset for that customer. Update any precedence rules for reconciliation based on the customer requirements.
Set up email and notifications specific to the customer	Notifications can be sent to different mailboxes based on the tenant associated with the ticket. As an MSP admin, you must configure mailboxes per tenant in the NTE:Config-EmailMailbox form. This will also require creating mailboxes per customer in the AR System. The Email engine does not support different engines running for different customers, so it would be the same engine, but using the notification and mailbox configuration, the inbound and outbound email can be segregated. Also, for inbound email, as an MSP Admin, you must configure the rules for how the emails are processed per tenant. The configuration of the rules is not protected by row-level security.
Set up infrastructure	A new realm must be created for a new tenant to set up the authentication and generate the URL for the tenant to use. For more information, see Request-process-for-BMC-dependent-activities.
Create services in BMC Helix Digital Workplace	As an MSP, if you have enabled the subcatalog functionality, new services specific to the tenant can be created. Tenant agents with subcatalog access can perform this action. For more information, see Assigning subcatalog roles to user accounts.
Create dashboards in BMC Helix Dashboards	As an MSP, you can create common dashboards for all your tenants. To learn how to set up BMC Helix Dashboards to use organizations to segregate data, see Managing multiple companies in BMC Helix Dashboards.
Set up integrations	The tenant must define accounts for integration specific to their companies. The integration user cannot have administrator access. The tenant can then create integrations that use the APIs to integrate with BMC Helix ITSM and other data in the AR System. As an MSP Admin, you must configure integrations via Atrium Integrator, as there is no segregation of accounts in Atrium Integrator per tenant. To use iPaaS integrations, accounts must be created for each company so that they can build the integrations separately from other companies. However, the accounts must be specific to those companies and not have admin or unrestricted access.

Onboard subsequent tenants in an existing multitenant environment

The process of onboarding subsequent tenants is like onboarding the first customer. The key difference is that live tenants are already working in the environment. Therefore, adequate care must be taken to ensure that any activity done as part of the onboarding process for a new tenant does not affect the existing tenants.

Global configurations cannot be changed for a specific tenant. Using the Data Management console, new foundation data can be loaded via spreadsheets using Data Management jobs. For more information, see Load Foundation data.

Example Company and Support Group model

The following graphic depicts an example of how Foundation data can be configured for an MSP and its tenant companies. The MSP company reflects the company and any related support groups that agents of the MSP will need to manage the environment. The MSP company must be a parent of the tenant companies so that agents of the MSP can access data for each of the tenant companies without having to manage access on a per-agent basis.

For each tenant, Foundation data is tied to the tenant company so that agents working for the tenant company can access only their data. For example, members of Customer Company A only see Company A data; likewise, members of Customer Company B will only see Company B data. Data that is marked as global can be seen by all customers including the MSP.

The suggested approach regarding data is that only new tenant-specific Foundation data be loaded into the system. Data Management would be the best approach to load Foundation data for a new customer into the system.

To learn how to use Data Management and different options for loading data, see Loading Foundation data by using Data Management.

Update a tenant

For Managed Service Providers, service updates containing patches, enhancements, and new features are deployed to your development environment first, then QA, and finally production.
To learn more, see Service update.

Promote data between environments

You must use the deployment management framework to create d2p packages and then move your company-specific data from the Development to the QA environment and from the QA to the production environment.
For more information, see Defining and deploying data and object packages.