Multitenant Deployment Architecture
Dynamics NAV supports deployments where several different companies access a centrally maintained Dynamics NAV application. By using this multitenancy support, you can add new customers to your solution easily, and you can roll out updates quickly with limited downtime for your customers.
You do not have to turn your Dynamics NAV solution into a multitenant deployment. You can install and run Dynamics NAV as a classic one-server-one-database deployment.
In a multitenant deployment, information about the Dynamics NAV application is stored in a separate application database. Your customers’ data is stored in separate business databases, each of which is a tenant in your deployment. By separating application from data, you can deploy the same solution to many customers with centralized maintenance of the application and isolation of each tenant. The application database contains the tables that define an application, such as the Object table and other system tables.
For example, if your current solution contains 10 companies in the Dynamics NAV database, you can choose to create separate Dynamics NAV databases to store each company’s business data. The knowledge about the shared application is then stored in a dedicated application database. Dynamics NAV includes Windows PowerShell cmdlets that create an application database, and other cmdlets that enable you to create and administer tenant-specific databases.
You can choose to upgrade to Dynamics NAV and not change your deployment so that you still have a single database that has one or more companies in it. You can also choose to extract the application tables to an application database but still have one business data database that has one or more companies in it. In both scenarios you have not migrated to multitenancy, but in the second scenario you have prepared your solution so that you can move to multitenancy at a later point.
Tenants, Companies, and Databases
A tenant is an entity that uses your solution and stores data in a business database. This is often either a business or a group of legal entities whose data can be stored in one database. In practical terms, a tenant is a database that stores business data for one or more Dynamics NAV companies. Each tenant is connected to a Microsoft Dynamics NAV Server instance, but the Microsoft Dynamics NAV Server instance can support multiple tenants.
When you deploy and maintain a Microsoft Dynamics NAV 2018 solution, you must activate the relationship between the Microsoft Dynamics NAV Server instance by mounting the tenant to the Microsoft Dynamics NAV Server instance. You can do this by using the Microsoft Dynamics NAV Server Administration tool or by running the Mount-NAVTenant and Sync-NAVTenant cmdlets from the Microsoft Dynamics NAV Administration Shell. Similarly, to disconnect a tenant, you can use the Microsoft Dynamics NAV Server Administration tool or run the Dismount-NAVTenant cmdlet. For more information, see How to: Mount or Dismount a Tenant on a Microsoft Dynamics Server Instance.
When tenants are mounted, the tenant configurations are stored in the dbo.$ndo$tenants table of the application database that is connected to the Microsoft Dynamics NAV Server instance. If you connect additional Microsoft Dynamics NAV Server instances to the same application database, the added server instances will automatically inherit the tenant configurations from the application database. This means that existing tenants will be automatically mounted to the new server instance. In addition, if you must mount or dismount a tenant, you only have to perform the operation on one of the Microsoft Dynamics NAV Server instances. The other server instances will automatically detect and update to the changes.
When you refer to a tenant, you refer to it by the tenant ID. The first tenant that is mounted against a Microsoft Dynamics NAV Server instance has the tenant ID default. However, you can choose to set up host names for the tenants in your deployment. For example, if you want a tenant to access Dynamics NAV through a URL, you can set up a tenant-specific subdomain. The users in that tenant will then access Dynamics NAV through a URL such as
https://mytenant.myservice.com. The tenant host name, mytenant.myservice.com, must be specified as an alternative ID in the tenant configuration. You can specify alternative IDs for a tenant by using the Mount-NAVTenant Windows PowerShell cmdlet.
A tenant database can contain one or more Dynamics NAV companies. It is not the number of companies in a database that determines whether you are running a multitenant environment. The deciding factor is whether you have created an application database, and if you have more than one tenant database connected to the application database.
When information about the application is stored in a separate application database, you maintain the application centrally without affecting the various tenants that use the application. Each tenant database contains the business data for one or more specific companies and does not contain all of the application metadata.
For example, if you want to modify a report, and your solution is used by 25 customers, you modify the report in the application database. When each customer then accesses the report, they see the modified report.
Deployment Scenarios Supported in Microsoft Dynamics NAV 2018
The following table compares deployment scenarios.
|Includes application database||No. of business databases per application database||No. of companies in business database||Multitenant deployment|
In the table, the number of companies and business databases are shown as either 1 or 2. But most of the time there are either 1 or more than 2.
The table describes different deployments of a Dynamics NAV solution. For example, a deployment with one database and a single company versus a deployment with two or more business databases for each application database. Of those two scenarios, only the second is a multitenant deployment because it connects multiple tenant databases (the business databases) with a single application database. The table also illustrates that you can have multiple companies in a business database. Finally, you can have an application database and a single business database that contains multiple companies. This is a single-tenant deployment.
The Application in Multitenant Deployments
In a Dynamics NAV application that is used in a multitenant deployment, some areas require you to set up web services. Since web services are created in the application database, you must create at least one tenant that has write access to the application database. This setting is determined by the Allow application database writes parameter when you mount a tenant against a Microsoft Dynamics NAV Server instance. For more information, see How to: Mount or Dismount a Tenant on a Microsoft Dynamics Server Instance.
For example, you can create a dedicated administration tenant that you mount against the Microsoft Dynamics NAV Server instance when you create web services for an application.
If you have an existing Dynamics NAV application that you want to use in a multitenant deployment, there are a number of changes that you have to make. This includes setting up the permission sets in a way that supports all tenants that use that application.
URLs and Tenants
In multitenant deployments, URLs must specify the tenant that the URL applies to. If you have C/AL code that constructs URLs, you must update the code to include the tenant. Alternatively, update your code with the GETURL Function to get the URLs calculated for you. The same applies to hyperlinks in report objects, for example.
The URL can specify the tenant ID or the tenant host name if you specify host names as alternative IDs for tenants. For example, the following URL consumes the Customer ODATA web service for a specific tenant:
If the mytenant.myservice.com host name has been specified as an alternative ID for the tenant Tenant1, then the following URL returns the same ODATA web service: