Using your RockRMS Organization Chart as a powerful tool for permissions

This guide is primarily intended for those who are just getting a RockRMS instance set up.  If your database has been up and running, you may be able to use some of these tips to help you out, but starting from scratch, this is one example of how to think strategically when setting up your internal Rock environment.

One of the trickiest things to get a handle on with Rock, coming from other church management systems, was the bewildering array of permissions that need to be handled.  Around our office, people have various implied permissions to do work based on their job description, so it made sense to extend that model into Rock.

As a note: While the concepts present in this tutorial are applicable to any organization, this is written toward an audience just getting started, in a very step-by-step fashion. Experienced Rock administrators may find some portions repetitive.

Prep Work

The first step you need to take, before you ever open up Rock, is to have a good, functional organizational chart of your church.  This isn't just an overall outline of who reports to whom - you'll want to have a good document of who does what.  If you don't already have this chart, take some time and draw yourself a map of who does what inside the church.  Start with the departments, then work down to the people who work in those departments. Figure out what roles there are.  At Highlands we have six separate organizational roles - Elder, Pastor, Leader, Staff, Intern, and Volunteer. 

Additional note: in every organization that I've ever worked with, there is a large gap between someone's job title, and what their functional responsibilities are. If you're planning on using this model to organize Rock and set permissions, what's important here is what a given person does, rather than what their e-mail signature may say their title is.

Four of those should be pretty self explanatory.  The leader role will generally be someone who's staff, not a pastor, but who has others in their department or departments who report to them.  To clarify about volunteer - we have very few people in our Rock organization chart who aren't paid staff members.  There are two or three specially trusted individuals who we use to perform specific roles within the database.  This is not the place where we store all volunteers throughout the church.

With our org chart in hand, there's a fair bit of foundation building that we'll need to do in Rock. 

Here are things we'll be doing:

• Adding some group roles to our RockRMS organization unit group type.
  
• Adding some Organization Chart groups to match departments in the church, and turning them into security roles
• Adding staff members to our Organization Units
  
• Making a secured dataview category, and a staff dataview
• Setting up a group sync to automatically grant RSR - Staff Worker rights to our staff members
  
• Filling out the dataview tree, report tree, and group tree with branches that match our org chart, and setting the permissions on them

Adding Group Roles to organization units

(tip: you should think about changing your theme color from the default orange - it helps to differentiate if you happen to be looking at the demo Rock installation, etc.)

The above animated gif shows the complete process of adding several different group roles to the Organizational Unit group type.

1. Using an account with RSR-Rock Admin permissions, navigate to Admin Tools > General Settings > Group Types

2. Select the group types button

3. Selecct the Organization Unit group type

4. Expand the Roles accordion

5. Select the 'Plus' button to add a role

6. Enter our role name. Choose whether we want users with that role to be able to view the organization unit. Tip - we don't need every different kind of job title in our church here, just functional roles.  At my church, we have staff with job titles of director, assistant, coordinator, specialist, etc. For the permissions that we're creating, there's no real difference between job titles.
   

7. Save the role entry.  Repeat as many times as necessary

8. Important! Remove edit rights from all Org Unit group roles, unless we've made a special Rock administration Organization Unit group type role.  Because we're going to be using groups to set permissions, it's important that only administrative users can add or remove people from Org Units.

9. Once all of the roles we need are entered, save the group type.

   
   

Adding Organization Units to the Org Chart

It's very possible that your church has numerous departments and responsibilities.  For our purposes, we'll make a few that can map to things within Rock in a logical fashion.  In the above .gif, we create a Finance group, set it as a security role, and then add a worker to the group. We'll add several other groups, "off camera".

Here are the steps we take:

1. Using an account with RSR-Rock Admin permissions, navigate to Intranet > Office Information > Org Chart
2. Click on the 'Add Group' button at the top left, and select "Add child To Selected"
3. In the "Add Group" dialog that appears, type in the name of your Organization Unit
4. Make sure to check the "Security Role" check box next to "Yes" - this will make this group into a security role that can be selected in permissions dialog boxes.
5. Save the new Organization Unit group
6. Since we're only making one group at this moment, we'll add Alisha Marble to the group by typing a partial first name and a partial last name into the person picker box. Alisha appears, we verify that she's who we wanted,  select her from the picker, then hit the 'Select' button at the bottom.
7. We quickly ensure that Alisha has the correct group role.  She's not an elder, pastor, intern or volunteer, so 'Staff' is appropriate.
8. We save the group member entry.
   

Adding members to Organization Units

We already demonstrated with Alisha how to add a person to an Organization Unit. One thing to definitely keep in mind is that people don't necessarily only have to be in one place. For example, Ted Decker is the Outreach Pastor.  We would put him both in the Outreach Organization Unit, as well as in the Pastors unit.  That way, any permissions that we wanted all of the pastors to have would apply, as well as any different permissions that Outreach might get.

At my church, our admin assistants have responsibilities in multiple departments. Kathy works at the front desk, as well as being an assistant to the Junior High director, the High School director, and the Student Ministries Pastor who oversees Junior High through College.  Kathy therefore belongs to the Junior High, High School, and College Organization Units, as well as others that pertain to other duties.

Making a secured dataview category, and a staff dataview

The dataviews that we're going to be creating here aren't super special, but letting unauthorized people get to them could have negative outcomes. Since we'll be making a few dataviews that are for administrative purposes, we'll make an "Administrative Dataviews" category, and secure it so that only Rock Administrators can even see that it exists, let alone create or change the dataviews.

1. Using an account with RSR-Rock Admin Permissions, go to Tools > Reporting > Data Views
2. Click on the "Add Category" button, then choose "Add Top Level"
3. Choose a category name.  For this, we'll use "Administrative Dataviews"
4. Save the new category.
5. Open the category permissions by clicking on the padlock button
6. Click on Add Role. Add RSR-Rock Administration to the View, Edit, and Administrate rights. (Do this every time you set permissions, anywhere in Rock. RSR-Rock Administration should always be at the top of any permissions list, with 'allow' checked)
7. Now to lock everyone else out, click on Add Role again, and add "All Users" to the View permission, then select the 'Deny' button.
8. Hit the 'Done' button in the bottom right.
   

Now that we have our secured place to put administrative dataviews, we'll make a dataview that grabs all our staff members.

1. Select the + Dataview button at the top left
2. Name the Dataview.  Here we have typed "Organizational Unit Members"
3. This dataview is for showing people, so in the "Applies To" drop-down, we choose "People"
4. We only need one filter for this dataview.  In the default filter that we're given, we want to grab people who are part of Organization Unit groups, and we'll narrow it down to just people who are paid to be in the office.
5. In the Filter Type drop down, we'll choose "In Groups (Advanced)."
6. From the list of groups, the Organization (or your church name if you've seen fit to change the root group) should be at the bottom. Select that
7. We'll want to grab any staff members from any groups we add in the future, so select the options for "Include Child Groups" and "Include All Descendants"
8. Once you pick the group, on the right you'll see any group roles that belong to those group types.  We will select "Staff" "Leader" "Pastor" and "Intern"
9. Save the dataview.  Now we can see that we have a list of people.
   

   
   

Granting RSR-Staff Worker permissions automatically with group sync

Group sync is a super useful tool to use for all kinds of tasks.  It lets a Rock administrator enable a group to be filled with people meeting some criteria, without having to manually change things in lots of places.

In this case, we're going to use group sync to automatically add anyone who we add as a staff member in our org chart to the RSR-Staff Worker built-in security role.  This role will give the staff member permissions to view the internal Rock site, as well as editing people, viewing groups, etc.

The main difference with this group sync setup is that the security role groups are hidden from prying eyes, accessible only to Rock administrators

1. Navigate to Admin Tools > Rock Settings > Security
2. Choose the "Security Roles" Button
3. Scroll down and choose "RSR - Staff Worker" from the list
4. Select the large "Edit" button in the middle left
5. Expand "Group Sync Settings"
6. Hit the + button toward the bottom right to add a new sync
7. On the left, select the "Organizational Unit Members" dataview that we just created
8. We will sync any people who are part of the OU Members dataview as members of the RSR - Staff Workers security role (select "Member" from the upper right drop-down box.
9. There are options here for sending e-mails or creating logins, but we won't take those steps right now. Save the Group Sync settings by hitting the button at the bottom right
   
10. Now Save the RSR - Staff Workers security role by clicking on the button at the bottom left.
11. Important - Group sync isn't instantaneous. It is a special job that runs in the background of Rock, by default every 20 minutes of the hour.  That is, it will run at 1:00, 1:20, and 1:40.  If you hit save on the security role at 1:11, go take a walk around the office for 10 minutes, and when you come back, your staff will all be members of the security role.
    

I also like to sync all my Organization Unit members back to the parent organization.  That way, if I add a new communications staff member, I only have to manually add them to the communications Org Unit, and they'll be added automatically to my "all staff list".  The steps are almost exactly the same as above, so I'll just leave the animated gif.

Making the rest of Rock march to the beat of our Organization Chart

This part may be the most time consuming.  For the sake of brevity (hah!) we will assume that the reader is able to add top-level groups, dataview and report categories, event registration catagories, etc.

We take our org chart, which looks like this:

Examining this tree, we figure out where else in Rock we can make trees that look just about the same. Here are examples of:

The group tree

The dataview tree (I would make the reports tree the same as the dataview tree)

And the Event Registration Tree

Notice that not all of the Org Chart groups are present in all of these trees.  For example, our "Pastors" Org unit probably doesn't need any event registrations.  It's not necessary to completely mirror everything.

Setting permissions for all of these main branches is effectively the same everywhere, so we'll only show setting permissions so that anyone logged in can view the students event registration entries, those in the "Students" organization unit can edit those entries, and only the Rock Administrators can do anything beyond this.

Important note that I learned the hard way: do not grant administrate permissions unless absolutely necessary.

50% of one year's VBS registrations were lost because a high-level volunteer was granted permissions that were too high for their work needs.

\> 

1. Using an account with RSR - Rock Administration rights, navigate to the Tools > Website > Event Registration page, where we've created the various categories in the tree to mirror our Org Chart.
2. Select the branch that we want to secure.  We'll choose the "Students" branch.
3. Select the padlock button on the right hand side to edit permissions.
4. The first thing we'll do, which should always be our habit when editing permissions, is to make sure that Rock Administrators have the access we need to keep things working. Select the View, Edit, and Administrate check boxes. Click on the Add Role button, then select RSR - Rock Administration.  This can be quickly done using the search bar at the top of the selector by typing 'rock' to bring up the role.
5. In the image, we quickly verified that RSR - Rock Administration has "Allow" rights for the three choices we just made. View and Edit boxes.
6. After this, we let everyone who can log in view the branch. Select "All authenticated users" from the Add Role search box.  Add authenticated users to the "view" permissions.
7. Finally, we block everyone who isn't an Administrator or a member of the Students Org Unit from making changes. Add the "All Users" group to the "Edit" permission. Once it's been added, navigate to the "Edit" choice at the top of the permissions dialog, and make sure that "Deny" is selected for the All Users role.
8. Quickly we look at the View and Edit permissions to verify that the everything is configured correctly.

This sequence should be applied to each branch that has been set up in each tree, whether Groups, Data Views, Reports, or Event Registration.  For some specific branches, such as Administrative or Financial Data Views and Reports, we will likely want to Deny view permissions to all users, except for Rock Administrators and the appropriate Finance Organization Unit.