Bursting Dashboards

[JoeM]

Introduction

Are you tired of manually generating and distributing reports to various stakeholders? Look no further! Bursting reports could be the solution you've been searching for. Bursting reports is a technique used in business intelligence that allows for the automatic distribution of reports to a defined group of recipients based on predetermined criteria. Additionally, by setting up bursting, you'll find the need to generate fewer reports on a per-stakeholder basis and engage stakeholders more deeply with pre-filtered data relevant to their needs.

What you need to know before reading this article

•  Bursting reports is a feature available to all cloud users starting in version 2022.11. 
• A foundational understanding of record-level security

Let's Go

What is Bursting? 

The idea of bursting has been around for some time within business intelligence. Bursting is the automatic distribution of reports to a defined group of recipients based on predetermined criteria. Some examples of bursting include: 

• Sales Performance: Bursting reports can be used to distribute sales performance reports to sales managers weekly or monthly. This way, they can quickly identify trends and areas for improvement.
• Inventory Management: Bursting reports can be used to distribute inventory reports to warehouse managers to ensure that inventory levels are optimal and that there are no stockouts or overstocks.
• Marketing Campaigns: Bursting reports can be used to distribute campaign performance reports to marketing managers to ensure that campaigns meet their objectives and that budgets are managed effectively.
• Financial Reporting: Bursting reports can be used to regularly distribute financial reports to executives and board members. This way, they can stay informed about the organization's financial health and make informed decisions accordingly.

Setting up Context

Before bursting is done, context needs to be set so we can understand which users or groups receive each report. In this example, we're going to take some seller quotes and revenues and ensure they receive a report relevant to their region:

First, let's look at the data:

State	Revenue YTD	Quota
California	1600000	1500000
Washington	870000	560000
Oregon	200000	750000
Utah	350000	500000
New York	1300000	2000000
Maine	200000	230000
Ohio	400000	500000
Michigan	350000	300000
Florida	350000	400000

In this example, we want to send states on the east coast of the US to our fake seller (joe.miller+east@incorta.com) and west coast states to joe.miller+west@incorta.com.

To set up row-level security, let's upload an Excel sheet showcasing which state each seller should see.

Login	Email	State	Admin	Admin Email
Joe West	joe.miller+west@incorta.com	California	admin	admin@incorta.com
Joe West	joe.miller+west@incorta.com	Oregon	admin	admin@incorta.com
Joe West	joe.miller+west@incorta.com	Washington	admin	admin@incorta.com
Joe West	joe.miller+west@incorta.com	Utah	admin	admin@incorta.com
Joe East	joe.miller+east@incorta.com	New York	admin	admin@incorta.com
Joe East	joe.miller+east@incorta.com	Maine	admin	admin@incorta.com
Joe East	joe.miller+east@incorta.com	Ohio	admin	admin@incorta.com
Joe East	joe.miller+east@incorta.com	Michigan	admin	admin@incorta.com
Joe East	joe.miller+east@incorta.com	Florida	admin	admin@incorta.com

Setting up an Internal Session Variable

Next, we need to set an internal session variable to create a list of states the logged-in user can see. 

query(
	RLS.Login_Info.State, 
	or(
		lower(
			RLS.Login_Info.Login
		) = $user, 
		lower(
			RLS.Login_Info.Admin
		) = $user
	)
)

Note: The or() condition ensures the admin can continue to access all states. Additionally, be aware that the user names are lowercase when pulled from the variables (hence using lower()).

Spoiler

If you are having trouble finding the correct user names, go ahead and create an internal session variable like this:

query($user)​

This will return the value the system is looking for:

Setting a filter

Now that we have the filter that returns the list of states the logged-in user is eligible to view go to the schema and table where the quota data is stored and apply the filter:

inList(
	Sales.Quotas.State, 
	$State
)

Now record-level security is operational.

Testing the Row-Level Security

If you have admin privileges in Incorta, the easiest way to verify the bursting behavior before sending any emails is to 'login as' other users who will become recipients. This can be done through the security tab, selecting a user, selecting the security tab in the side rail, and selecting 'login as.' 

Setting up the Schedule

Before any scheduling, double-check to ensure that all recipients can view the delivered dashboard. 

1.  Go to Share > Send/Schedule Report
2.  Select 'Burst Report'
3. Add the desired recipients
4. Finish any other configurations. 

Viola! Your report has been delivered!

Best Practices

• Ensure all users or groups have view access to the report being delivered.
• If you are working on bursting multiple reports, consider making a group. By doing so, future additions/subtractions to recipients will be managed dynamically and not on a per-schedule basis.
• Be sure to test it before sending it! We spoke of using user impersonation above, but did you know that for Google / Outlook accounts, adding a '+' qualifier after the email name but before the domain will be ignored?
  • Example: example+user1@incorta.com and example+user2@incorta.com will both send to example@incorta.com. This is useful for emulating different users but landing all burst reports into the same inbox for verification. 
• Ensure that all burst recipients have logged in.  To receive a report, users must have logged into their Incorta account once to have created their password. If your bursting dialogue notes a sender error during the scheduling process, verify that the users have view access and have logged in. 

Related Material

• Record-level Security
• Incorta Security Guide