Removed permission create workspace - WHY?????

Hi JoeBlackwell​

I see your problems and I agree that restricting the creation of new workspaces to "beginners" might help. But if you cancel the "create" option it is still possible for end users to create/move tables with the shared project until they get completely wrong numbers. I think you can't get rid of the problem you describe, you can just limit the options that it happens. Giving you my vote, let's see if others agree and we get restriction back again.

Thank you urs.boller​ i really appreciate you taking the time to review this.

Unfortunately the removal of the permission creates real problems for us:

!/ We have setup the product profiles so we have a set of profiles for report suite access and another set for tools access i.e. workspace. This means we can pick and choose report suites and individual tools we want users to have. We already adjust the dimensions available for agency staff which means we have to create a duplicate of the report suite profile. If we were to then also start setting up profiles for different user levels we will end up with loads of duplicates of many report suites. Turning our product profiles list from simple and clean to a massive mess.

2/ We currently use a VRS for all users to clean and block certain data. If we remove dimensions from the VRS then it stops that report suite working with reports & analytics and it can only be used in workspace. This is not a problem for about 50% of our users as we stopped offering access to R&A however we have 150 legacy users still using R&A and if we alter the VRS then it will stop their access. If we created a separate VRS for use in R&A then it will also be fully available in workspace.

The biggest issue I have is that previously when creation access was denied the only workspaces users could possibly access were ones where we had pre-built everything for them. It made it simple to use as they could see how it was meant to be setup and reduced problems of misinterpretation. However now every user regardless of expertise can create a blank workspace. Even if we limit the dimensions they can still create a blank workspace with no clue how data changes just by where it is placed together in a table. As I mention before the only thing they could access before was a curated project with a pre-built table.

I know we can use templates but these are hidden in the custom menu and still doesn’t stop users creating a blank project.

I just don’t understand why there was a need to remove this permission. What is the business logic or customer experience improvement for this needing to be removed?

Hi JoeBlackwell​

I made some testing and I think it works quite well. I managed to restrict access to metrics and dimensions as needed. The only thing I couldn't control is that an end user can create new workspace projects. But I don't mind if somebody creates a new one as long as he is not able to share to groups (just single other users ...)

Product profile "only workspace"
The settings for this profile looks as follow:

• Access to one report suite
• Access to all Metrics and Dimensions (auto-include)
• Access to "Analytics Tool" => "Analysis Workspace Access"

Sharing project with "Curated Project Data"

When sharing a project where I used "Curate Project Data" to a selected amount of items, the end user can only access to those items. He has no way to get to other elements within this project.

user can "save as"

With this setup the user can still hit "save as..." and save the project in his local project repository. When doing this, the access to items (metric and dimensions) changes. That means the user has now access to all Metrics/Dimensions based on the Product Profile AND the ReportSuite. Therefore a user can add any Metric or Dimension he wants.

restrict access to metric and dimensions

basically you have two options to restrict the access to the full list of Metrics and Dimensions

1. in "Product Profile" select the Items a user should have access to (both Elements and Metrics)
2. create a "Virtual Report Suite" and manually select the "components" that should be available for this VRS

Both options change the way the test user could access to the data: he was not able to access any item outside the defined list.

Recommendation

Since you are talking about basic access for user with maybe little knowledge about the data (and the usage of workspace) I would recommend to use 2) above and create a VRS. I can think of at least 3 reasons why you should go that way

• Easy filtering out "bad traffic" or "restrict to certain data". That means you don't need to add any global segments to your projects, it's already included in the VRS. Just think of a global filter as "exclude bot traffic" which you would normally add to all your projects. in a normal project a end user could remove that segment, not possibel in a VRS
• Within a VRS you could change the names of the variables and give them friendly names the user understands. That means even if your variable is called something like "site section", you could rename it to "domains and subdomains" (or whatever the end user understands immediately). This is not possible when you give access to the original report suite
• In case your end user needs access to different report suites which don't use the same Events and Dimensions (or worse: have completely different data in the same variable), you can restrict access per Report Suite. You could do this even in the Product Profile by creating a bunch of Profiles for each combination of Report Suites and Access Level. But using VRS with restricted components can save you some work. that means you give your end users access to all Metrics and Dimensions while the restriction is made by the VRS! this way you just manage the access to the VRS for the Users while having the restriction in a friendly interface within analytics.

I hope that those information help you to create a good setup where you can restrict the access as desired.

Thanks for the reply urs.boller​ we have migrated to the experience cloud. I have been through all the permission in the product profile for Analytics and i can see no option to making workspace read only. I can also find no reference to this in the articles you sent. The only related permissions i can find are 'Analysis Workspace Access' and 'Analysis Workspace - Save As Template'. What am i missing as struggle to see a read only option????

Analytics Product Profile Permission List

Server Call Usage

Code Manager

Code Manager - Web Services

Logs

Logs - Web Services

Traffic Management

Permission Management

Permissions (Read) - Web Services

Permissions (Write) - Web Services

Security

Support

Web Services

Single Sign-On

Pending Actions

Co-Branding

Preferences

Hide Report Suites

Excel License Users

Current Data

Ad Hoc Analysis License Users

Mobile App Admin

Activity Map

Analysis Workspace Access

Web Service Access

Report Builder

Reports & Analytics Access

Analysis Workspace: Save As Template

Calculated Metric Creation

Segment Creation

Advertising Analytics Management

Segment Publishing

Integrations (Create)

Integrations (Update)

Integrations (Delete)

You can restrict access to workspace projects as read only by change of permissions (product profiles).

Here are two links which are worth having a look:

• Manage Experience Cloud users and products
• Product Profiles |

In case you are still in the old legacy world, just go to user groups and change permissions in the first block of settings...