Who should be the OneStream application administrator?
The skill set needed to administrate an OneStream application is very valuable. Luckly you should not need to look farther than the team you have that supports the application. Not only the key resource for your project but also identifying the right person to support your application after you have taken it live, but the administrator is also critical to the system. The most common questions people seem to ask are first, where should this person sit? No, not where should they physically sit, but should the person be in an IT role, or a Business Functional role? I think the question comes from the fact that at some point they have seen some scripting, and that means coding, and that usually means an IT person. The reality is that the level of scripting is that of writing a macro in Excel. This really is not programming. So, it is easier to teach a businessperson how to write these types of scripts, than it is to teach an IT person debits and credits. Frankly, there are accountants who don’t know debits and credits out there. The administrator needs to know enough to ask the next question. That person needs to understand ‘what is the end game’, so they can think of that works within the whole system. For example, let’s say a business user comes and asks for a roll forward to be added to the application. They are very specific about what they need and the accounts. A good administrator who understands the business process will think to ask about a validation to reconcile it to the trial balance. They will ask about the filings or management reports that are impacted. They will also know who in the accounting team might need to weigh in on who should have access, if it is something all sites need to do, and how it impacts the close. It turns out, adding accounts and updating a roll forward is a very small part of the request. The second question people ask all the time is, ‘how much time is this going to take?’ that is when I give my safe consulting answer, ‘It depends’ (that answer gets me out of so much trouble, I frankly don’t know what I would do without saying it) Still, it is the truth. It does depend. It depends on who the administrator is in your company. If the person understands the close process, and what users really need, they spend less time trying to understand how people are using the system. It depends on how much work you took on during the project. If you only loaded one year of data, they will be pretty busy loading data for months later. It depends on your company. Is the company culture one that requires buy in from users, and fills days with meetings of large groups of people who need to reach a consensus? Then it will be much longer. Most administrators have another job. They are not only the OneStream administrator. I get the chance to talk to auditors at different companies, and when I tell them what I do, we start talking about OneStream. Many have told me when they had a question about the consolidation; they found the only person who really knew how it was calculated was the OneStream administrator. Even if the administrator doesn’t know the way it “should be” done they know how is “currently being” done. So, think about the person who you are having do that work. They become not only critical to the application, but critical to your close and your businessLocking (and Unlocking) OneStream Security
How often are you, as a consultant or OneStream administrator, scrambling before UAT or go-live to get all your business rules working, all your workflows setup and tying out data? And you completely forget about security (because you as an Administrator can see and do everything), until the final hour? Sound familiar? Do not let security be an afterthought to your OneStream implementation, project, or on-going maintenance. Security leaves a first impression and has a direct and tangible impact on your end users. So, getting security right from the get-go (UAT or go-live) can go a long way to user acceptance! Let’s talk about some common security strategies and things you need to consider before you get to the week prior to UAT! These things will help you think about security along the development cycle or even as you add in new elements to an already live application, so that you can layer security in as you go, avoiding that last minute scramble. User Roles During the design phase, get a list of everyone who will be end users of OneStream, whether you have 10 or 1,000+ users! Put those users into broad categories or types of roles those users will have in OS. These are some examples (Chapter 4 of the Security Essentials book 😊): VIEWERS: People who can view all data and reports with no restrictions DATA LOADERS: People who will be involved with bringing data into OS whether via Imports, Journals or Manual forms entry APPROVERS: People with oversight of a process with the ability to certify, lock or determine when the data is final FORECASTERS / PLANNERS: People who will be involved in inputting data and running calculations related to a forecast or budget process POWER USERS / LOCAL ADMINS: People who will have broader access than the average VIEWERS with the ability to perhaps modify reports, metadata, etc within OS Role Access For each role or type of user you will have, outline what each role should be allowed (or not) to do. For example: VIEWERS Ability to see all cube data meaning all entities, all scenarios, all cubes, etc Access reports for such data from: OnePlace Spreadsheet Dashboards Be allowed to view the dimension hierarchy page to understand how things roll up Be allowed to view FX rates Once you have determined a framework for what a given role or set of users is allowed to do, you are read to put the building blocks together to achieve that. Pre Security Build Before I start to set up security and/or ahead of a UAT, I like to start by making all application objects (app roles & pages, cube views, metadata, dashboards, BRs, etc) set from “Everyone” to “Administrators.” Why do I do this? I like to keep things inside OneStream under lock and key and only grant access on an as-needed basis. In this way, as you start to put together your end user security groups users will only be allowed to see and do things to which you have granted them access. Not only does it help you control data access, but it also helps simplify the end user experience. You will only open up access as needed so as not to overwhelm your users. If you leave all doors and windows opened and unlocked (as with a house), well you can imagine what a security nightmare that could be! This approach works well for complex organizations or companies who have strict governance around data. If your company does not have strict security needs or your user base is small, then this approach of locking everything down to start, may not be the best approach for your security model. If you are early in build and/or because you have not done anything with security to-date, things will generally be wide open (“Everyone”). This is because as you add new elements to a OneStream application (cube views, entities, scenarios, etc.) the default security group, if you do not change it, is “Everyone.” So before heading into a UAT I like to start by locking everything down (e.g. “Administrators”) and then proceed with putting groups in place to open things back up. What is the easiest and quickest way to lock everything down? I like to do a full application extract to XML. Then I methodically open each XML file: And make the following edit and replaces: CURRENT VALUE REPLACE WITH VALUE accessGroup="Everyone" accessGroup="Administrators" maintenanceGroup="Everyone" maintenanceGroup="Administrators" "WorkflowExecutionGroup" attributeValue="Everyone" "WorkflowExecutionGroup" attributeValue="Administrators" "CertificationSignOffGroup" attributeValue="Everyone" "CertificationSignOffGroup" attributeValue="Administrators" "JournalProcessGroup" attributeValue="Everyone" "JournalProcessGroup" attributeValue="Administrators" "JournalApprovalGroup" attributeValue="Everyone" "JournalApprovalGroup" attributeValue="Administrators" "JournalPostGroup" attributeValue="Everyone" "JournalPostGroup" attributeValue="Administrators" readDataGroup="Everyone" readDataGroup="Administrators" readWriteDataGroup="Everyone" readWriteDataGroup="Administrators" "CalculateFromGridsGroup" value="Everyone" "CalculateFromGridsGroup" value="Administrators" "ManageDataGroup" value="Everyone" "ManageDataGroup" value="Administrators" readDataGroup2="Everyone" readDataGroup2="Administrators" readWriteDataGroup2="Everyone" readWriteDataGroup2="Administrators" Then load each XML file back into your OneStream app. Alternatively, you can consider using the Solution Exchange tool called XML Security Remover: Which will allow you to take an app extract zip file, run it through this Solution Exchange tool and set all security to “Administrators” via this tool. Both should accomplish the same goal of changing all security groups to “Administrators.” Then, if you poke around within the application, you should generally see “Administrators” applied to everything. To test this you can set up a native user ID and log in as that user. If everything has been locked down, that user should not see any applications. Their drop-down box at the log in screen will be empty. Goal achieved – every window and door in your OneStream castle is locked! Now what? Now you are ready to start putting user groups together and layering on the security that will allow your users to unlock and walk through certain doors (e.g. pages, objects or data in OneStream). Building Security Groups and Roles Create a user group 000_GRP_VIEWALL (see Chapter 3 of the Security Essentials book for security group naming conventions). Figure out the pages or application roles to which they will need access and create those groups (or decide to leave some open to “Everyone”). 3. Now that you have a user group (000_GRP_VIEWALL) and have allowed that group to get to certain pages within an application (001_APP_OPENPROD, 001_APP_VIEWALLDATA, 001_APP_DIMPAGE, 001_APP_FXPAGE, and 001_APP_SPREADSHEETPAGE), you are ready to move on to determine what, if any, other object or data security this user group needs. 4. Being that this is the View All user group and because you have granted 001_APP_VIEWALLDATA, this user group should not need any additional data access for 002 Cubes, 003 Scenarios, and 004 Entities. The View All app security role supersedes those things. However, you will likely still want to grant this view all user group access to a WF profile such as an actual WF group: 005_WF_ACTUAL. Testing The final step is to nest groups and test that user’s security role access. The easiest way to achieve this is to set up a native User ID, e.g. “Test1”, and log in as that user. For obvious reasons, you do not want to log in with your “Administrators” access because you can see and do everything. You want to mimic an end user by either logging in as a native user set up with a particular user group, or have yourself temporarily removed from “Administrators” and placed into whichever group you wish to test. Here are some basic steps to testing: Nest or combine the various 001 – 005 security groups into your 000 user group as shown below: Log in as Test1 user (or your own user ID if necessary) and test the end user security. Confirm that you can get to the screens for which this user group (000_GRP_VIEWALL) should have access as well as NOT get to pages and places for which you do not want them to. Part of your testing should be to focus on the end user experience and navigation options available to the end user. You want to confirm that the user can get to what is needed, but also not get to that which they do not need access or which could serve to confuse them. Conclusion You will want to repeat similar steps as you put together your additional user groups: 000_GRP_DATALOAD_ACTUALS 000_GRP_APPROVE_ACTUALS 000_GRP_FORECAST_WRITE 000_GRP_POWERUSER 000_GRP_LOCALADMIN_PROD The process should be to establish the user groups (000) listed above, determine what application roles (001), cubes (002), scenarios (003), entities (004), workflows (005) and other data objects to which they need access. Create these security groups and attach them to various application objects, embed them in your 000 user groups and then test. The same holds true if you have already established security and are making changes to your security model. You will want to log in as the user before you make changes, make the group changes, then log back in after and ensure you see the intended consequences of your changes. The same approach can be used whether you are establishing security for the first time, or making changes years down the road. They key with implementing or changing security is to test and retest. Only you, as the consultant or company OneStream administrator, knows to what each group should or should not have access. So who better to test than you?! Of course, your end users will ultimately test their security as a part of a UAT or parallels, but the hope is that you have worked out all, if not most, of the kinks before the end user logs in. This can go a long way to building end user confidence, acceptance, lessening frustration, and speeding adoption of OneStream. You could build the nicest house (OneStream application) on the block, but if you do not provide the right people the right keys to the front door, it will be for not! And, it will likely save you headaches in the long run. Security should not be an after thought. It should be considered as a part of the overall OneStream design, put in place during the build cycle and tested ahead of a UAT, go-live or before you turn things over to your end users. For more information on all these topics, please see the OneStream Security Essentials publication now available.
