User Access Permissions are a crucial aspect to maintaining the integrity of a financial (or any other) system. Team members from Accounts Payable, for example, shouldn’t necessarily be editing revenue schedules. Accounts Receivable team members may not need to see the employee bank account information used for expense reimbursements. For general health of the system’s data integrity and for proper security of the data contained in the system, user access permissions are a must as a company grows and has more than just a couple people in the accounting team.
Switching to Role-Based Permissions
When I moved out of the Marketo accounting team into IT, there were two other team members who had just attended an Intacct admin training course and came back raving about role based permissions and how we needed them. At the time, Marketo used user-based permissions and not role-based permissions. While using user-based permissions was an effective way to start as a small organization, the team had already grown to over 40 active Intacct users, and each time a new employee came on board, the employee’s manager would say something like, “Please set the permissions the same as mine." I’m sure you’ve heard this story, and if not with Intacct, then with another system.
If you’re not an admin, you may not realize, the result was that the admin was spending literally hours checking boxes to enable each permission one at a time.
Hundreds of boxes for each user. Trying not to fall asleep…
Since I didn’t understand this is what our admin needed to do when I first heard of role-based permissions, I didn’t realize this was a priority project to work on. Not until both of the other admins went on vacation, and three new users started in that same week.
Ah! So I have to go check hundreds of boxes for this purpose? Not a chance.
Luckily I had a meeting scheduled at Intacct headquarters in San Jose the next day and raised this up. Here’s what they said in case you’re nervous about switching to role-based permissions: When you first change the configuration from user-based permissions to role-based permissions, Intacct will automatically create a role for each user. No impact to the current day to day activities for the users! Then, if you have a role for Employee A, and Employee B comes on board, it’s simple to choose Employee A’s role and add it to the new user record!
We switched practically immediately during the meeting, and what I thought was going to be a day long project to create those three users was done in five minutes.
Choosing the Roles
While some companies may decide to assign one role to one job title (like Sr. Revenue Analyst or Jr. Account Payable Clerk), that didn’t seem any more efficient to me than having user based permissions. While each company can decide what works best for them, here’s what we did at Marketo.
The Intacct product allows for multiple roles to be assigned to one user. We came up with a listing of the functional activities that each team performed and divided roles by activities. There were many items that almost all of the team should be able to perform, like creating journal entries, running reports, and viewing the financials. For these permissions, we created a role called Base Permissions. The only people that do not get this permission is our System Admins, external collections users, employee users, and CRM users.
We also have other categories such as: Accounts Payable, Add/Edit Vendors, GL Maintenance, Order Entry, and Revenue. For system super users, we have a Reporting Admin role which can be used to create new custom and financial reports. We also have a few Supervisory roles: AP Supervisor, GL Supervisor, Revenue Supervisor, and AR Supervisor. These roles allow access to open and close subledgers, delete certain types of transactions, and approve certain types of records.
Marketo went from 100+ distinct combinations of checkboxes to 30 defined roles, which could be applied in the correct combination on a per user basis.
User Access Review
Introduction of user roles is one thing, but it is highly suggested to perform a user access review on a quarterly basis. Marketo performed this review as a part of SOX controls as a public company. Even after becoming private, this is an activity that will continue on. Why?
● It saves money. While Marketo has an integration with Workday which automatically disables users in Intacct when the related employee leaves the company, the automated process could fail, and a user could remain active. Without a regular review, we could be paying for users we don’t need anymore.
● People move around to other teams and job responsibilities shift. Someone who used to apply cash might not have that function in their role anymore as he or she shifts to a collections focused position, for example. A regular access review will help identify who still has the roles related to their old position and not their own.
● Processes change. If anyone can perform an activity in the system and the process behind that activity needs to change, it can be difficult to make sure people from multiple teams who all have access to the activity also know to do it the new way. Limiting activities to people in certain roles, ensures data entry consistency and helps to make sure that the people with access are performing the activity correctly.
How to do a Review
Depending on the sophistication of the company, a review could be done as simply as creating a custom report of the active user listing including the user roles as a part of the custom report. But, in true Marketo fashion, we had to go all out. Here’s our process:
1. We use Alteryx to pull the following information via API:
a. Employee data from Workday (active and inactive, including employee ID and term date).
b. Intacct User Info to get employee ID, user status
c. Intacct User Role to get which roles are attached to the user.
d. Intacct Role Permission Info to get which permissions are assigned to each role.
2. Parse the information and send as an Excel file into a folder on Box.
3. Run an Excel Macro to macro to break the file up into tabs for reviewers and make it look pretty.
4. The Users each have a permission approver as a custom field on the user record. Each permission approver is responsible to check the following:
a. Should the user should still be under his or her review or be moved to a different approver?
b. Should the user still have access?
c. Should the user keep the current roles?
5. Each Role also has a permission approver who will make sure that the permissions assigned to each role are still appropriate.
6. Make the updates in the system.
Overall, this may seem complex, but results in much less admin work in setting up new users and maintaining existing ones, not to mention greatly helping in maintaining the integrity of the data in the system.
...which as we all know, is always completely perfect at the end of each month.