Data Visualization sharing from Platform Analytics Workspace

[Kavya2]

In the Classic PA we had OOTB role report_user which used to only let users with role to create and save the visualizations but was not allowing them to "SHARE" it with anyone.

Now we have this viz_creator role which lets users with this role create, save and also "SHARE" data visualizations they have created.

My concern is if we let everybody with this role (our organization gets it by default as reporting is a self-service) "SAHRE" visualizations especially those data visualizations that use "table" as the data source might be concerning to the platform because

- Every time it is accessed by the user that it is shared with, it will hit the underlying transactional table and produce the results.

- If users with viz_creator role keeps sharing these visualizations with anybody and everybody without knowing how it can impact, wouldn`t this turn out as the biggest platform load causing the platform degradation if there is an increase in users accessing such visualizations?

I would like to know if sharing access of data visualizations by  viz_creator role is recommended? (It is already allowed by the viz_creator role anyway).

Is there a way we can restrict this role to prevent sharing data visulizations where the data source is a table because of this reason. If your answer is to customize the ACL for it, I would like to understand the step by step guidance because I haven`t really done ACLs before and our platform team suggested ACLs cannot be implemented for such cases.

If not ACLs, are there other ways we can achieve it and how?

Look forward to the solution?

@Adam Stout @Thomas Davis

[Josh Cooper]

Good day!
Typically the queries that are run when visualizing reporting data are pretty light, since it tends to be aggregated data (counts and sums of things that meet a criteria instead of loading complete records).  You're correct that loading the visualization is going to query the underlying table if the data source is the table type, but it's not likely to have a noticeable impact.  One of the benefits of the way ServiceNow operates as an application is that the data layer just runs the query and gets out, so even in situations where users who are performing work in a table may have the record open for 10 minutes making notes and reading comments, the actual impact to the server is just for a few milliseconds on the initial load and the update.  Depending on the size of your instance, there are several dozen concurrent sessions that are allowed for the duration of those milliseconds, so through typical usage patterns you're not likely to ever queue up those queries more than a few milliseconds.
I definitely understand the concern though, but this is essentially the same as historically when we would have reporting widgets on a Dashboard and then the dashboard itself was shared.  There was only one time I remember it ever being a problem, and that was when one of the leaders of a major organization was impressed with the dashboard so he encouraged a few thousand employees to go check it out during a company town hall meeting, which caused thousands of people to hit it all in the space of a few seconds.
The datacenter team at ServiceNow also has monitoring tools to see if those sorts of things happen and has a process to mitigate it, especially if it becomes a pattern.
I definitely appreciate the desire to get in front of any potential problem that may affect load, though.  One easy way to get in front of it may just be to communicate to the creators to be mindful of who they share the visualizations with.  Not just for load purposes, but also just to avoid sharing what might be a very interesting visualization with hundreds of people who aren't interested in it.  
One concern against modifying ACLs is that it can be very difficult to understand all of the potential impacts that may have on other related functionality in the system.  While changing an ACL may solve this immediate concern, you may find 4 or 5 months from now that some capability that's important, but not commonly used doesn't work as expected, and it may take so long for the issue to surface that it requires a large amount of time to discover the issue that caused it.  From that perspective I'd caution against changing an ACL or other code until or unless you know it's absolutely necessary.
The general rule I used to use as an architect was don't try to fix through code what you can address through process.  The example is, you can use ServiceNow to make a Short Description field mandatory, but you can't prevent someone from typing in just a period.  So you can then add a rule that makes sure it's at least 10 characters long, but you can't stop them from typing in 10 periods.  So you can add a rule that checks for repeating characters... etc. etc.  Instead of adding all those things, the easiest answer may be to require everyone who puts a period in the short description to go through a training course on proper form filing. 
Hopefully this helps somewhat!