Removed permission create workspace - WHY?????

[#1]

We had built a series of curated workspaces that gave our end users a set of carefully selected projects to be able to interrogate the data. They restricted the projects to simple sets of data making it easy for our users and also restricted them having access to the full set of dimensions which we didn't want them to have.#

We did and do not want our non analyst community to be able to create their own workspaces but rather use the ones we had created for them. They were pre-built, simple to use and controlled.

What you have done now is open up the full workspace to everyone. We wouldn't have dreamed of giving our non-analysts access to Ad-Hoc analysis yet we are now giving them access to create uncurated projects in the more powerful workspace with the full range of dimensions.

Why have you done this???

[#2]

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...

[#3]

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)

[#4]

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.

[#5]

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?

[#6]

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.

[#7]

Hey folks. Good discussion here and I like urs.boller​'s suggestion to create a Virtual Report Suite to restrict access to data. That's what I came out here to say, and he had already said. Urs is, as usual, one step ahead!

To answer the original question, we're not totally thrilled with the decision to remove the Create/Curate permission ourselves. Unfortunately, there were some issues with the way that permission was engineered, and it put us in a tough spot where we ultimately decided that the best course of action was to fall back to other permission options (restricting dimensions/metrics, VRS curation, etc.) but allow anyone to create a project. I understand the frustration as it sounds like you were using the permission the way we had hoped people would use it. I wish there had been a better way in the short-term. The good news is that Adobe Analytics Product and Engineering teams will be revisiting the permission model and sharing and curation workflows in a future release, so please be patient and hopefully the other options for limiting the "overwhelmingness" of blank Analysis Workspace projects will tie you over until then.

[#8]

Oh no... you've effectively opened Pandora's box. :-(

Right from the start we have been very careful to only give this permission to trusted  users.  This permission was essential in preventing workspace becoming the mess that the old reporting & analytics interface was.

The other issue here is once people have access to something it becomes potentially politically difficult to take it away regardless of whether they can be trusted to use it.

Even if you do restore the permission, I dread to think of the clean up that will needed to do to restore order if this is left like this for any time.

I really hope this gets addressed soon.

[#9]

Since my first post earlier this morning I've had a chance to investigate and reflect on this.

Unfortunately, I fear Adobe have broken our governance and operating model with this decision.

Up until this point the majority of our users couldn't create workspaces.  This forced those users to engage with us when they had new requirements which meant we had the opportunity to:

• Point them to existing workspaces if what they were requesting already existed (maintaining a single source of truth)
• Where needed, build new workspaces (or add to existing ones) maintaining a consistent standard
• Educate these users on the workspaces to ensure they were understood and used correctly

We have only been on the experience cloud login a couple of weeks and I can see that we've already had 20+ random workspaces created that my team were not aware of (and this is with all the mitigations suggested above already in place).

The issue isn't the "overwhelmingness" of workspace, it's the fact that casual users think they know what they are doing but they don't understand all the complexities.   It's about our ability to protect users from themselves and maintain a centralized version of truth which has unfortunately been significantly degraded by this decision.

I know you (Ben) has called for patience but it is difficult given that the longer this goes on the harder it will be to put a lid on this.

[#10]

I don't think the Virtual Report Suite is the way to go as things stand.

I have created a virtual report suite that contains very few dimensions and metrics. This is for the specific purpose of allowing a partner company work with us.

I have discovered that they can view dimensions outside those defined within the VRS is they save as their own version. They can see and access a list "Non-Curated VRS Components"

[#11]

Andrew Wathen​ - how has the past 4 months been going? Is this still an issue that you are dealing with? I am curious because we starting to go down a similar road.