Showing results for 
Search instead for 
Did you mean: 
Not applicable

When using Sisense, a lot of the focus is on the data and the analytics, but just as important is the ability to share these insights with colleagues and collaborators. This poses some administration challenges concerning  who has access to what and who can share with whom.

One of our most popular add-ons to control access and sharing issues, is the “Limit Share Auto-complete” add-on, which we recently integrated into the product, and I’m here to share with you how and why we decided to do so.

What does the add-on do? 

Simply put, it limits the list of people and groups with whom a user can share assets in the application. Only those who are actually in at least one group with the user can have access. We call it “limit auto-complete” because it removes results from the auto-complete search in our share interface. By enabling this capability, the administrator of the application can choose if sharing assets should be available between everybody, or create specific groups to allow sharing. In most cases, this has been  used to define internal tenants, and separating groups of users.

One of our goals when working with add-ons for the Sisense application, is to identify what’s needed and used by our customers, and integrate these “favorite” features into the product as add-ons. As we work to introduce more application multi-tenancy capabilities to our product and give more control to our administrators, this was a clear candidate   to become a productized add-on.

So, how did we do it?

The first step was to identify what use-cases we needed, and if there were any more requirements that were  hidden behind the simple scenario I mentioned above. With a more robust multi-tenancy solution in the making, the main question was, “Why do we need both, when we can just limit the users to their own tenant?” A closer examination showed two additional use-cases. 

The first, for a full multi-tenant environment, was an additional layer that controls sharing, but  gives customers more flexibility and control. It’s something  several customers  specifically requested.

The second was actually for an internal use case, where a company would want to limit the capabilities of different departments to share, or even be aware of users from other departments. HR can share with Management, but Engineering might not need to even be aware of who is in HR.

As we set about solving these use-cases, a whole world of possibilities opened up to us. We discovered that we should provide additional control over whether specific groups could be shared at all. We work to define which types of assets could be subject to such access limitations, and we could better define the different capabilities and limitations according to the users’ roles and permission levels. 


Having the add-on as part of the product has opened up  more options to better control the system configuration. Although integrating add-ons requires additional installation and maintenance, having this capability out of the box is just a single line in our configuration section and much easier for us to maintain and for  customers to work with.

What’s next?

We’re always looking to enhance our product and expand its capabilities. So far, we’ve  simply introduced the capability inside the product, but we won’t stop there. Coming next is the ability to exclude sharing from  specific groups , and defining which assets have limited access.

To read more you can check our documentation here: