Key Points about the Baseline ACT Approach

In general, it isn't necessary to add protection to the predefined folders (such as the root folder, each user's My Folder, and the System folder). These folders are protected by default.
The preceding examples don't add grants of ReadMetadata permission on the DemoBranch folder because that folder's parent (the SAS Folders node) is visible to all registered users. The grant of ReadMetadata permission to SASUSERS on the SAS Folders node flows into the DemoBranch.
To hide a branch, apply the Hide ACT to the relevant folder and grant back ReadMetadata permission to any groups who should have access. Remember that a denial of ReadMetadata permission on a folder prevents navigation to content and folders that are below the hidden folder (and that this can't be mitigated by a grant of ReadMetadata permission on a lower-level folder or other item).
To enable a group to contribute content to a particular folder, give that group a grant of WriteMemberMetadata permission on that folder and consider applying the Protect ACT to each immediate subfolder.

Note: This protects lower-level folders that inherit the contributing group's WriteMemberMetadata permission grant (from the parent folder) as a grant of WriteMetadata permission (on the child folder). If you don't protect a child folder, the contributing group can rename, delete, or change permissions on that folder. To enable content contributions to the child folder, grant WriteMemberMetadata permission on that folder (and consider repeating the denial of WriteMetadata permission on any subfolders that are below that folder).

Note: Any content contributors who register cubes must have WriteMetadata permission on the OLAP schema. By default, the schema is in the SAS Folders/Shared Data/ SASApp - OLAP Schema folder.
If you want a group to access data through cubes, information maps, or the metadata LIBNAME engine, give that group a grant of Read permission on the folder that contains the relevant items. For any folder where you add a grant of Read permission, determine whether you want that grant to flow through to the subfolders. Apply the LimitData ACT to any immediate subfolders where you want to prevent data access. The navigational requirement for a clear path of ReadMetadata permission doesn't apply to the Read permission.
The examples in this chapter ensure that content contributors have Read permission to the resources that they use. If you have a content contributor who isn't also a content consumer, you can choose to not provide Read permission. For example, if you give a user ReadMetadata permission but not Read permission to an information map, that user can still design the map (but can't perform tasks such as testing queries).
You might be able to save some time by using this technique:
1. Create one sub-branch (for example, the DivisionA branch in the preceding examples). The folders should have appropriate permission settings but contain no content.
2. Copy that empty sub-branch to create the other branches (for example, to create the DivisionB folders). Change the folder name on the copy and update the settings as necessary. Often, you only have to remove and add a few supplemental grants.
Note: If this technique proves useful, consider keeping an empty template branch that is visible only to administrators. You can use the template if you need to add more branches later.