Managing Business Application Groups
Business Application Groups can be created to organize a collection of Business Applications related to an enterprise for better management.
A Business Application Group can contain multiple Business Applications. Within a Business Group, there can be several groups.
Adding a Business Application Group
- A Business Application Group can be created by clicking the Add option on the Business Applications homepage or by selecting New Business Application Group option from any Business group's context menu in the Explorer view.
- Customers can name their business group something meaningful that suits them. The next crucial step in the process of creating a Business Group is to assign it an access policy. Customers are asked to select the Service principals that the Business Group and its inherited groups and applications can access. The access policy can be changed any time.
Editing a Business Application Group
- The basic Business Application Group information and its Service principal access policy can be changed at any time.
Removing a Service principal will automatically remove the Service principal and all resources associated with this Service principal in all inner levels of this group.
Deleting a Business Application Group
- Customers can delete a Business Application group by selecting the Delete option from the context menu of the relevant group in the Explorer view.
Within this Business Application group, all the Business Applications and child Business groups, as well as their configurations, will be deleted.
The deletion of a Business Application Group takes approximately one minute. It will take at least a minute to update the License consumption.
Each Service principal is assigned to the root Business Application group by default. As a result, there is no way to change the root Business group's Service principal access policy.
When a Business Application or a nested Business group is moved into a parent Business group, the parent group's Service principal access policy takes precedence, and the resources associated with the parent Service principal are overridden.