How Can We Help?

Search for answers or browse our knowledge base.

Documentation | Demos | Support

< All Topics
Print

Object Grouping

Purpose

This article will cover scenarios in which you would organize the view beginning with your client account. You may have already read through the Platform Navigation document that talks a lot about the object tree or the Administration configuration that talks about cross-client access, but let’s expand a bit more.

There are some considerations as to why you would organize certain ways such as being a Service Provider, corporate entity, or government organization. Each of these may have a more specific way of organizing, yet there might be similarities. One common consideration for building the object groupings is multi-tenancy, which can be all within one organization or with a service provider having many customers. Use this article and the concepts given to help find the best way to organize your portal as best fits your organization.

Overview

  • Service Provider
  • Non-service Providers

Service Providers

It’s important as a Service Provider to be able to provide services to all your customers. It’s also important to keep all your customers separated from seeing each other’s data. Let’s break down how one might set up a service provider.

  • It starts with the client level when a new account is created and from that top level you have access to creating more client objects as a child object.
Create Client as child object
  • This results in having multiple clients underneath the Service Provider Client.
Multiple Child Clients
  • Once a Client logs into their account they will only have access to their view and data.
Customer logged in

This is typically where the Service Provider becomes hands off and the customer is then able to deploy Aggregator/Collectors to scan their environment. However, depending on the services offered by the provider the customer may allow for the service provider to have access to their information. The easiest way to do this is by allowing Cross-Client Access. This setting here allows the parent object to access data. More info on enabling can be found here.

Cross-client on vs off

One thing to keep in mind is that an organization may not be a service provider in the way they bring on any customer. Universities could provide services to the different Schools and departments across campus regardless of having a centralized or decentralized IT department. Or a parent company that has a separate IT team and initiative compared to their child companies. The Aparavi Platform can then function as a service for these organizations to have a full view of all data across all companies.

Non-Service Providers

As an organization that is not defined as a Service Provider, this could apply to many different categories such as government, healthcare, finance, and corporate companies both big and small. You as a client could use the Aparavi platform directly, or as a client through a service provider as discussed above. In either case you have the same options from your client level.

Another use case for the Aparavi Platform is Mergers and Acquisitions(M&A). In the corporate world this is between two or more companies that are coming together as one entity, or in the higher education vertical a university adopting a centralized IT. With these examples its important to know the data before bringing it all together.

  • Starting at the Client Level you have options to add another object. The two objects outside of aggregator and collectors would be Client and Group. For this example we want to use a new Group.
Add new client or group
  • The group we will create is called Merger and Acquisition.
M&A group
  • From there we are now able to add Clients into the group.
Multiple clients as part of group

The great thing about this is that it still allows the clients to have the option to give cross-client access especially if this is just prep-work prior to the merger to get an understanding of the amount and type of data.

Here are two other examples of why creating groups might be important:

  • Location
    This is a great grouping category especially for organizations that have many locations that have their own sets of data. This would allow for aggregators and collectors to be deployed in such a way that each group would have multiple. It can even be broken down further with groups within groups. Such as the United States being a Group and containing States as groups below it.
Groups by region
  • Department
    This grouping may really come down to how shares are presented and who might be in control of the shares. A great example would be a university where there are many schools and departments across campus. The central IT can create a group for each school or department that gets added to the platform. And in corporate organizations the typical Sales, Marketing, Accounting, etc. departments could be set up as their own group.
Groups by departments

Groups make sense a lot of times, but it comes down to the organization and how they want to view their data.

Conclusion

Like other areas of the Aparavi Platform, Object Grouping gives the freedom and flexibility to do what’s best for the organization. There is not a one size fits all way to set up the clients and the groups, but looking at the way your organization is dispersed, whether that’s by geography, departments or both being a good way to start. Beyond setting up groups, the option to create more clients works well for a multi-tenant environment primarily for Service Providers, but this can be used by any Aparavi platform user to help with multi-tenancy between locations or departments.

Was this article helpful?
0 out Of 5 Stars
5 Stars 0%
4 Stars 0%
3 Stars 0%
2 Stars 0%
1 Stars 0%
How can we improve this article?
Please submit the reason for your vote so that we can improve the article.
Previous Tagging
Table of Contents