Cost Object Permissions
The tasks below can only be performed by users assigned to the Admin or Budget Process Owner roles. For additional information on roles, see Frontdoor permissions and roles.
Watch this video from Apptio Education Services: Configuring Reference Data: Financial Dimensions and Cost Object Permissions.
Or see all Apptio planning video and training resources.
Dimensions are the essential data categories in budget line items. Many built-in dimensions have dependencies on other dimensions (see Reference data attribute and dimensions dependencies for more information). You can import dimensions reference data from a .csv file or from Costing Standard and export dimensions reference data templates and table data (see Manage dimensions).
The Cost Object Permissions dimension determines who can perform actions with Cost Objects. Each Cost Object can have one or more users associated with it, and users can be assigned to that Cost Object with edit-level and approval-level permissions. Once permissions are set up, the approval workflow is separated from the Cost Center hierarchy.
- In the navigation menu, select Configuration > Cost Object Permissions.
- View the Cost Object Permissions in either List or Hierarchy view by selecting the toggle option at the top right.
- Select Export > Export All (on the top-right) to download the .csv file.
- Open the downloaded .csv file and update the data values as required:
- Cost Object - The unique identifier for a Cost Object, organized in lists that correspond to each Cost Object type (Departments, Services, Business Units, and Projects). The Cost Object reference data itself may be organized into parent and child hierarchical relationships.
- User Name - The user name to grant Cost Object Permissions.
- Edit Level - Permissions for the Cost Object user. Options include the following:
- Owner - Can view, edit, submit, and approve that Cost Object level (including any child Cost Objects).
- Edit & Submit - Can view, edit, and submit, but not approve, that Cost Object level (including any child Cost Objects).
- View Only - Can view, but not edit, submit, or approve that Cost Object level (including any child Cost Objects).
-
Can View Sensitive Columns - To see columns marked as sensitive on Labor line item table schema. This is applies to both the Labor tab and the Summary tab. FAQ: Hide Sensitive Labor Data
-
Can View Sensitive Financials - To view Financials which are generated by the Labor line. In the Summary tab, they can see read-only generated Labor line items for the Cost Object. FAQ: Hide Sensitive Labor Data
Example
If your department hierarchy includes multiple levels, you may want to flatten the approval workflow. You can configure the approval hierarchy to skip certain levels, so that the departments within the node you skip will roll up to the next-level owner. In the following image, Group E, Group F, and Group H are "skip" nodes. The departments within those groups would be approved by the next level owner: plan for Department D and Department E would be approved by the owner of Group B.
Enhanced Sensitive Data Hiding
If you have an organization structure where you have users who own managing labor headcount and financials for their respective department or group department level, you need to provide them edit permissions for the respective departments or group departments. But at the same time if you want these users to be able to view the labor financials or labor headcount at a higher department hierarchy excluding the sensitive data for visibility and awareness, you will have very specific needs to manage the labor sensitive data for this use case.
For example,
In the above example, user CCO2 has been given Editor access at APPDEV department. Since the permissions cascade down top to bottom in the cost object hierarchy, CCO2 will automatically get the Editor access on the child cost object hierarchy for APPDEV, whether or not specific access is provided to CCO2 user.
Notice that CCO2 user is not given Can View Sensitive Columns access at APPDEV level. But CCO2 user has Can View Sensitive Columns access at APPDEV L3, a child cost object hierarchy in APPDEV.
With the new changes in ApptioOne Planning 3.43 release, we have introduced a different permission cascading behavior for the sensitive data permissions. Which enables controlling permissions at granular level.
In the above example since CCO2 user doesn’t have permission to view sensitive columns at APPDEV level, the same permission will cascade down in the department hierarchy until it finds a cost object/department either group or leaf where the permission to view sensitive columns is provided. If it finds one, then that permission takes precedence over the top-level permission.
Because of this change it is now possible to provide CCO2 user access to view sensitive columns at APPDEV L3 even though CCO2 doesn’t have permission to view sensitive columns at a higher-level cost object APPDEV.
You will also notice that CCO2 user has been given explicit access to view sensitive columns on leaf cost objects APP-BO and APP-SALES, but there is no explicit Can View Sensitive Columns permission given at APP-LOB. But irrespective of that CCO2 will be able to view sensitive columns at APP-LOB because the top level cost object APPDEV L3 permission will cascade down to lower-level child cost objects. In summary, it is not required to give explicit permission to view sensitive columns on all the leaf cost objects of APPDEV L3 if the permission to view sensitive columns is provided at APPDEV L3, it will cascade down to lower-level cost objects under APPDEV L3.
Check the screenshots below to understand the difference between old behavior and new behavior when handling sensitive data permissions.
Previous behavior (Prior to ApptioOne Plan 3.43)
New behavior (After ApptioOne Plan 3.43 release)
The example above is specific Can View Sensitive Columns permissions, but same rules also apply for Can View Sensitive Financials permission as well.
NOTE: The non-sensitive data permissions (Editor, Owner and View Only) work the same way as before. The change is specific only to sensitive data permissions.