If you read my previous posts about how to use the live data connection to your BW system I hope you have built many stories by now! So the question may arise: How do I actually structure all these stories in SAP Analytics Cloud (SAC) and how do I implement an authorization concept? Well, this post is all about structuring the content and defining an authorization concept in your SAC tenant!

You will learn about:

• The file system of SAC and a possible content structure.
• Recommended workflow.
• Authorization concepts (Roles, Teams).

File System of SAC

Let’s start with explaining how the file system of SAC works. SAC uses a hierarchic file system with the System node as root. Below that is the Sample folder which contains SAC’s default sample stories. Then there is the Users folder which contains, for every user created in SAC, a user specific folder. These folders are also known as My Files or “Private” folder. A Public folder acts a a globally available container which, by default, can everyone see. Last but not least we have the Team folder. Each team in SAC shares such a folder. You can create many more sub folders for each of the described folders to accommodate your corporation’s needs.

This graphic illustrates the described system:

Important: To fully explore the file system you need the required rights + you must use the Browse -> Files menu to start the file browser. While the file browser offers filtering and browsing of files, the “content view” (Browse -> Stories) is restricted to display a flat list only. However, this view allows the user to use filter presets like “All”, “Public”, “My Stories”, “Shared with me”, “Samples”, “Templates”. Additionally, the unified search allows to search by story name, description and creator.

Public

This should be regarded as your verified source of truth. Only content which is approved, checked and adheres to any reporting guidelines (brand and KPI definition) should be placed here. Think about structuring the public folder further and creating sub folders to group the content by topics and/or organizational units.

To ensure that only verified stories are placed in the public folder a workflow must be established:

Team

Teams can be used to group together users. Think about teams as smaller organizational units. But you might also have some teams which span whole regions or are cross-functional. Each team has a system generated folder which can be used by any team member. They can create as many sub folders as required. Teams also offer some benefit when it comes to setup the authorization, which we will discuss a bit later.

User

Also known as the “private” folder. Here the user can create as many stories and sub folders as they want. Content can be shared to a whole team (recommendation is to use the team folder to make the ownership explicit) or to single users. When a document is owned by a single team member or for better access control the story should be created in the user folder and shared to the team with appropriate permissions.

Authorization

You should now have an idea what is possible in terms of organizing your content in SAC. Let’s have a look at what we need to setup on the authorization side to support our file structure concept.

Folders

Public and private sub folders can be shared with other teams or single users. In addition to the story sharing authorizations “New Documents” and “New Folders” authorizations are available. Public sub folders are by default shared (but this can be changed).

Stories in “team folder”: Any team member has read/write/update access (no full-control: no story sharing). Beyond that the story can be shared to other teams/users by the owner of the story. Sub folders in the “team folder” cannot be shared.

Story sharing

When sharing a story the following authorizations are possible:

• Full access: Encompasses the following authorizations and changing the sharing options.
• Read access: Allows opening the story, changing input variables and filters (without persisting the changes)
• Update access: Changing the story (editing and persisting)
• Delete access: Deleting the story

Teams

Think about how many teams your organization needs. Keep it simple to lower the maintenance effort. Besides just being a convenient way to share something to a larger group of people teams are required to setup the authorizations in the public folders. If you create a sub folder in the public area then you can limit the visibility to only certain users or teams. Therefore it might be good to create a “global” folder which is available to everyone and then create some other folders which are limited to certain teams based on your organizational units.

Roles

SAC offers some default roles but you can create additional roles tailored to your requirements. The built-in BI_ADMIN role is the system administrator with all rights (beyond the here stated objects). Note that we have two additional administrator roles (ADMIN_MODEL and ADMIN_USER) which support a segregation of concerns. Also the BI_CONTENT_CREATOR_PUBLIC role helps in implementing the mentioned approval workflow. Combining these considerations I suggest the following role setup:

Read: r, Write/Update: w, Delete: d

Conclusion

I have shown you how SAC structures the content and how you can influence that. You are now able to define a content structure which fits your organization’s needs. In addition, I have introduced a simple concept of approval workflow to ensure correct stories are in the public folder. Finally, you have learned about the authorization possibilities and some proposed roles. Keep in mind that this post is focused on live connectivity, meaning that no planning features are used. These may implicate some further requirements for those authorizations.