My organisation has been trying to move to using curated Virtual Report Suites. However, we have had to abandon these plans because of the following 2 main problems:
Details of the issues encountered...
There are now 3 administrative capabilities relating to segments:
Unfortunately, they interact with each other in bizarre and contradictory ways. However, all the problems seem to stem from the “Customization of Virtual Report Suite Components” capability.
This is because:
When a user creates a segment it is not a curated segment within the virtual report suite and is therefore blocked from appearing in the left-hand rail.
This break a well establish workflow leading to much confusion as segments do not appear where users expect them.
(Note: users aren't actually blocked from using segments they've created as they still have the capability within the panels to create segments in the project.)
Hi Andrew. thanks so much for pointing to that problem, saved me a lot of work figuring it out myself (just saw an issue but didn't have the time to investigate).
I fully agree that sharing segments/metrics should be independent of VRS, the same as the are independent from RS.
Basically there are 2 options for sharing/restricting access to segments/calc. metrics (if you exclude the product profiles, but I leave it out right now):
Somehow I have a bad feeling about the second solution. because what I miss in the current setup is sort of "definition where to use a calc. metric/segments". let's say I want to give access to a calc. metric, but please use it only in VRS 1 and 3, not 2. Think of it as having eVar67 all over your RS, but it is not really used. The management of the eVar access is managed in the RS settings (and access in the product profile). But as far as I know it's not possible to see an eVar which doesn't exists in a RS (even if I have granted access in the product profile to the eVar for that RS)
according to that example with the eVar, I somehow prefer to have an option on the VRS and define what metrics/segments are allowed (or useful). this way you can give access to a bunch of items and later restrict access based on the data they are working with.
But again, I fully agree that it is not clear or at least I would expect the same behaviour as you described above. Maybe the solution is somewhere between, or a combination of both permission management options described above: let's share AND have management on a VRS.
remark: I don't know if it is the right way to add "RS" access within the calculated metric manager. on one hand you give access to metrics on the VRS, not on the metric (example: you define eVars within RS Settings, there is no global eVar-Settings to manage RS). but on the other hand, a management of permissions in the calc. metric manager would allow to include/exclude all RS as well, not only VRS.
I just read the new Release Notes (Experience Cloud Help). there have been some changes on VRS and project curation. does that already solve the issue or is it still a mess?
ursboller thanks for the heads up!
I'm going to use some test logins to work out what impact these changes have made. I'll try and post the outcome in the next few days.
maybe I'll get the time to do some testing on my pen, I'm interested if everything works as expected... happy to hear again!
Hi Andrew Wathen
Just tried to setup a VRS and a product profile for easy access, especially for beginners. The result ist just far away from what I would expect ... Now I understand what you mean by "messed up" ...
Finally got some time to go thru this in detail. As far as I can work out, the users experience does not match what is described in the help article: VRS and project curation
If it did work as described I think it would be quite usable. However, the key different is that if the VRS is curated, non-admins cannot access the segments and calculated metrics that they own.
This is in contradiction to the help article that states non-admins should be able to access "Non-curated VRS components that the role owns or that have been shared with them"
As there seems to be a direct conflict between what actually happens in Workspace and what is described in the help article I have logged a Client Care incident which is being looked into. I'll let you know how I get on.
Client Care have confirmed this as a bug. If anyone wants to ask client care about the status the Bug ID is: AN-175616
...there may be some light at the end of the tunnel!
I got a similar ticket open... waiting to be resolved until we can roll out the VRS...
Its a mess how it currently works, users are getting frustrated about not having access - and I din't want to give full access to the main database ...
Don't know if you've heard anything on your open ticket, but I chased Client Care today who got back to me to say they were targeting April's release for a fix.
Hi Andrew, thanks for the update! no, I haven't heard anything since a while - eagerly waiting that this mayor bug is beeing resolved...