Administrator Checklist

After install you will see an Administrator's Checklist on the homepage. Don't worry; only administrators will see this block. The welcome block below it will greet a majority of your colleagues.

The Administrator's Checklist block gives you a list of things you'll want to complete before you get too far along in your deployment of Rock. Once you've checked all of the items off, this block will disappear, but not forever… After an update there may be additional configuration steps required before you're able to use a new feature. These steps will show up in this block after the update. Think of it as an old friend who shows up in your hour of need (not like your old college roommate who only shows up at the worst possible times.)

Quick Links

You'll see a Quick Links section on the right side of the screen. This is a great place to organize links that your organization uses most often. Some churches have used this section to provide links to:

• The online catalog for ordering office supplies
• Referral lists for counseling and pastoral needs
• The organization's webmail site
• Project management tools the organization uses like Basecamp or Asana
• Facility management tools like ServiceU
• Common Forms

Active Users

Under the quick links section you will see two sections that list active users on the internal and external website. This allows you to see who is active on the site. Clicking on the name will take you to their Person Profile page.

Workflow Tasks

Next on the homepage you will find a list of workflows that pertain to the currently logged in user. This is broken down into two areas.

1. My Tasks This lists out active workflow tasks that are currently assigned to the currently logged in user.
2. My Requests This lists all of the active workflow requests you have launched.

Be Creative

Don't limit yourself to what was provided out of the box. While we'll be providing new blocks for you to add to your homepage (like staff anniversaries and birthdays), you can get started today with some simple, but powerful, tools. Below are some ideas to help get the juices flowing.

• Pastoral Messages: Below the welcome message, add a new HTML block that is secured so only Pastoral staff can see it. This is a good way to share information without overloading the screen with content that only a few people need. You can modify the security of this block to allow an approved group of people to modify it (freeing yourself to work on other tasks.)
• Team Messages: Similar in concept to the pastoral messages, you can secure an HTML block to be seen only by specific teams in your organization.

Org Chart

Under the Intranet section you will also find a page for configuring an Org Chart. This is simply a group viewer that is specifically configured for helping you develop an organization chart. It's often helpful to have an org chart in Rock that you can use to configure access to parts of the application or for use in configuration. If you don't think you'll need this you can simply hide it from the navigation by setting the Display When setting to Never on under Page Properties.

Keyboard Shortcuts

In at effort to speed up your interaction with Rock, we've added several keyboard shortcuts. Let's take a look at what's available:

Entities

The word "entities" is used to describe the classification unit of different types of data in Rock. For instance People, Groups, Financial Transactions, Locations, Pages are all different entities in Rock. If you’re familiar with databases, entities are very similar to tables. In fact, most entities in Rock have an associated table in the database.

You might be asking, "Why do I need to know this?" For the most part, you don’t have to know a thing about entities to successfully use Rock. But, you will see the term in many of the configuration screens so it’s good to know what it is.

Defined Types / Defined Values

Many of the configuration items in Rock are made up of a list of valid values. Think about the Marital Status of a person. While we could have made this a textbox where anyone could type in the marital status of a couple, in today’s world, that could be a disaster. You’d probably get a million different answers to that question. Instead, it's better to provide a list to limit the options to those that make sense to the organization.

The "valid value" concept is prevalent in numerous areas (Record Status, Phone Types, etc). Instead of creating separate screens and logic for each of these, we came up with the concept of Defined Lists. These lists are made up of values (Defined Values) that you get to configure to match your organization.

Change Password

This is where the logged in user can change their password.

Communication Templates

This page allows the current user to create personal communication templates.

Configuring Protect My Ministry

Rock ships with a seamless integration with Protect My Ministry for background checks. Below is a series of steps to get you up and running in no time.

Step 1: Sign-up

The first step in the process is to sign up for the Protect My Ministry service. To do this, start at the Protect My Ministry page under Admin Tools > System Settings > Protect My Ministry.

Should you choose to register for a new account by clicking the Register For An Account

After completing the registration, come back to the Rock PMM page and enter in the username and password you created. You will then be taken to the Protect My Ministry Detail Page.

Step 2: Configuration

Once you've entered your PMM account information, you will see the details of your account.

You'll now want to configure the packages that are tied to your account. The most popular packages have already been made available to you through the integration. Each package has a brief description that outlines its specific merits.

There are several configuration settings for each package. Let's look at each setting and what it means.

• Package Name This is the PMM name for the package. It must be an exact match to what's in their system, so please don't change it unless instructed to.
• County Criminal Default County Depending on your state it may be recommend that you provide a county on your request. If so this will be the default county to use if one is not present on the address of the person you're checking. You can find out if your state needs this county using this map from PMM.
• Use Home Address for County Criminal Again this will depend on the state you live in. If your state is recommended for the county search, you will want to enable this option.
• State Criminal Default State This is the default state to use when doing a state criminal request. This option is defaulted to the state that is most common in your database, but feel free to change it.
• Use Home State for Statewide Criminal This setting determines if the state from the address should be sent.
• MVR Jurisdiction Code This setting determines jurisdiction to use for MVR (Motor Vehicle Records) searches. You can select your area from the list provided. (this is only needed for MVR type searches).
• Use Home State for MVR Search This determines if the state from the home address should be sent for the MVR search. (this is only needed for MVR type searches).

While you can add new packages using the settings above for the most part, the packages provided should meet all your needs. You may need to edit some of the configurations to meet the recommendations for your state. This decision centers around whether you should be doing a state or county search. PMM provides a map to help you determine what is best for your area.

Viewing Requests

From this same screen you can also view all of the requests that have been processed. This list is provided to help you see what's being processed from a high level. As you'll see soon, it's much easier to see the results of a specific background check request from the workflow and Person Profile pages.

Processing Requests

Several different organizational needs kick off a background request workflow. For instance, you may be looking to hire a new staff member, complete the screening of a potential volunteer, update existing person profile records or transfer a staff member or volunteer into a new position. At any rate, whatever the reason, it is usually a staff member who first needs to start the request for a background check.

To see if an individual has had a background check done, go to the Person Profile page and look under the Extended Attributes tab.

Every logged in user will be able to see either a Yes or No in the Background Checked field. Background Check Admins can also see three additional fields, and have editing privileges.

1 Background Checked:

Will have the checkbox either checked or empty.

2 Background Check Date:

Will have the date the check was completed, if applicable.

3 Background Check Result:

Will show either Pass or Fail.

4 Background Check Document:

Will have a complete PDF of the background check results, if a check has been completed.

How It Works

The Lifecycle Of A Request

1

A staff member will initiate a request.

2

The request will be sent to notify the individuals in the 'Background Check Administrators' security role.

3

If the request is denied, a notification will be sent to the requestor, who can then update the request and resubmit it or cancel the request.

4

If the request is approved, it will be submitted to your organization's background check provider to be processed.

5

If the background check comes back as 'Pass', Rock will update the Person Profile page with pass/fail results and a PDF copy of the full report. The requester will also be emailed an update of the completion.

6

If the check comes back with a status other than 'Pass' the workflow will notify the individuals in the 'Background Check Administrators' application group to review the results and determine if the background check should be passed or failed. The results will then be emailed to the requester.

Workflow

The background check workflow has eight possible activities. And like many other aspects of Rock, it's customizable. You may find that you'd like to configure your background checks a little differently for your organization. For instance, you could add a step to the process after a staff requests a background check that notifies a volunteer to provide their own social security number.

To review or modify the workflow configuration, go to Admin Tools > General Settings > Workflow Configuration > Safety & Security > Background Check. For more details on workflows in Rock, see Blasting Off With Workflows.

Location Descriptors

When you create a location, you can define several location descriptors: street address, latitude/longitude point and geo-fence.

• Street Address: This is pretty obvious, the street address of the location.
• Latitude / Longitude Point: The lat/long point is simply the latitude/longitude of the location on the map. You can set this by either providing an address and allowing Rock to convert it to a lat/long (assuming a Geocoding Service is configured) or you can reference the point using Rock’s location picker.
• Geo-fence: A geo-fence is a virtual perimeter for a real-world geographic area or boundary. Geo-fences are used by Rock to define things like regions for groups and to power future mobile applications like check-in.

Types of Locations

There are two types of locations in Rock. Let’s take a look at each and see how they are used by Rock.

Address Standardization and Geocoding

Your attendees' addresses are very valuable, so it's important that they are formatted correctly and validated through the USPS database. Also, in order for these addresses to be used with the latest mapping technologies it's important to convert them into latitude and longitude points through a process called geocoding. Fortunately, Rock makes both of these tasks simple.

As addresses are entered into the system, Rock can send them to one of many online services to standardize and geocode them. These services will ensure that:

• Addresses are formatted correctly (e.g. fix upper / lower case issues)
• Items like Streets, Avenues, West and East are abbreviated correctly
• Zip+4 is researched and added
• Latitude and longitude are added to your addresses

You can set up these services under Admin Tools > System Settings > Location Services. There you will see a list of services that Rock supports. Not every service supports both standardization and geocoding.

Email Settings

The configuration items you provided during the install can be updated under Admin Tools > Communications > Communication Transports > SMTP. Email is sent from Rock using a communication transport. Think of this as a delivery service. Just as you might pick between sending your package via UPS or FedEx, Rock gives you options when sending out your emails. Currently, the only transport that is complete is the SMTP component (more to come soon).

Sending bulk email is difficult in today’s age of spam and spam filters. Simply configuring an ISP or Internal Exchange Server is not enough if you want to be sure that all of your messages will make it to their intended recipients. To do that, you need to make sure your DNS has proper SPF and Domain Key records and monitor that you are not on any blacklists. Even for the largest organizations, this can be an overwhelming task.

Wherever a problem exists, a new service will be created to help solve it and that has certainly been the case in the area of email deliverability. With the importance of email and the complexity of getting your environment right, it makes sense for most organizations to outsource the sending of their emails. These services specialize in getting it right and the pricing is fairly reasonable. Rock ships with the Mailgun transport, but you can check the Rock Shop for integrations with other transports such as SendGrid.

These services do require some minor changes to your organization’s DNS settings, but they walk you through the process online to make it easier.

Security Roles

The basic access control unit is the Security Role. While you can provide security specific to an individual, it's often overly tedious and problematic to define security access down to the individual. Using Security Roles is much more flexible and less prone to error.

Having a well thought out strategy for security roles is critical. Too simple and your users might have more rights than they need; too complex and security will be difficult to maintain. We've worked hard to build a foundation for you to build from in this area. Below is a list of security roles that come with Rock with a description of their usage. We strongly recommend looking over these roles and reading their descriptions before you start setting up your staff and users. You can find these roles under Admin Tools > Security > Security Roles.

Permissions

Wherever you see the you can manage the security of the item being displayed. This will bring up the Security Editor show below.

1Actions

The first thing you’ll see is a tabbed list of the security actions available for the item. Normally these will be View, Edit and Administrate. You will set permissions for each of these actions.

2Item Permisstions

The Item Permissions list the specific permissions defined for the item. If there are no specific permissions set for this particular item, the permissions will be blank. Instead, security is being inherited from its parent. But now we’re jumping ahead...

3Inherited Permissions

Most items don’t have permissions of their own. They inherit their permissions from their parents. For the most part, you’ll only add Item Permissions when you want to increase the security of the item. This is a very powerful concept. It keeps you from having to constantly and consistently tweak the security of each item. It also allows you to change the security of an item and let the change trickle down to all of its children.

Questions About Updating

Do I have to update to the latest version?

Depending how often you update, you may see several updates available. You don’t necessarily need to update to the latest and greatest version. You can update to any version you wish. Doing so will install all of the previous updates to that point.

Can I skip a specific update?

No, updates are cumulative so you cannot skip over a specific update or patch.

Duplicate Finder

The duplicate finder routinely goes through your database looking for records that could be duplicates. When it finds possible matches, it scores them and lists them for you under Tools > Data Integrity > Duplicate Finder.

1 Confidence:

Indicates the likelihood that this is a duplicate record.

2 Name:

The first and last name of the individual.

3 Record Count:

The number of possible duplicate records for this person.

4 Modified:

The date and time the duplication record was modified. This is another data point to help you determine if a record is a duplicate.

5 Created By:

The person (or possibly application) that created the duplicate record. This helps determine how the duplicate may have come into existence and which data point might be more accurate.

Clicking on a row will take you to the duplicate detail screen.

The top row represents the source record and the rows below represent possible duplicate records. If any of these rows are duplicates, you can select them and select the fa fa-users in the grid footer to merge them. Each record has a series of buttons to the right. These buttons perform the actions defined below.

• Will open the person profile page for this individual in a new window.
• Tells Rock that this record is definitely not a duplicate to the record above.
• Tells Rock that there is currently no way to be sure if this record is a duplicate of the one above. This will keep Rock from showing it as a possible duplicate until more information is available to help determine its true status.

If you're uncertain whether two records are duplicates or not, you can simply decide not to do anything yet. As more data is added to the records, Rock will update the match scores to reflect a more accurate prediction.

Detail minded folks might be interested on how the percentages are calculated for duplicate records. The out of the box logic compares two records based on a points system. Points are awarded based on the following factors:

• Email Matches (4pts)
• Partial Name Match (First 2 characters of the first name plus full last name) (1pt)
• Full First Name Match (3pts)
• Full Last Name Match (3pts)
• Cell Phone Match (4pts)
• Non-Cell Phone Match (2pts)
• Address Match (2pts)
• Birthday Match (3pts)
• Gender Match (1pt)
• Campus Match (1pt)
• Marital Status (1pt)

A percentage is the calculated by comparing the number of points scored by the total possible points.

Reports

There are several clean up reports that have been created to help you identify records that need your attention. Feel free to add your own reports here. Each of the reports that ship with Rock are documented below.

Workflows

Workflows can be set up to help automate the process of data integrity. Feel free to add your own. We've outlined the ones that come with Rock below.

Location Editor

The location editor allows you to edit and clean locations in your database. Because there are so many locations in your database (think every address) the list will only show items that match the filters you provide. A common use for this page is to edit the geocoding for a specific address. There is a filter to show you addresses that are not geocoded.

Once you select an address you can chose to view it's details and edit it. Below is a view of the edit screen.

Photo Requests

When new photos are submitted by the organization's members they will be displayed here to ensure that they are appropriate. You can read more about the photo request in the Person & Family Field Guide.

Merge Requests

If a person selects people (person records) to be merged but they do not have security access to complete the merge a merge request will be created and listed here. By default, you will not have security access until you are listed on the Merge People page with read rights.

Rock Update

Updates are one of Rock’s best features. Many systems require tedious updates. And many times only the vendor can complete them. Not so with Rock. When an update is made available, all you need to do is visit this screen. Details will be provided about the updates available. When you’re ready, you simply click the Install button. Rock will then download and install the updates for you. How easy is that?!

Global Attributes

Global attributes are the basic configuration settings that are used to customize Rock. Each has a default value that you can override. Many of these were set for you during the installation process. Below is a list of the core settings and descriptions.

Defined Types

Defined Types are settings that are specific to a certain feature. In the list, you’ll find settings for Check-in, Giving, Marketing Campaigns, Metrics and People. Each of these will be discussed more in sections relevant to each feature, but let’s look quickly at how you can edit these settings.

Each Defined Type can have multiple values (cleverly called Defined Values). To edit the values for a Defined Type, simply click on the item in the grid you want to edit. You will then be taken to a new screen where you can edit its values.

Group Types

The Group Types screen is used to add new types of groups and modify those that already exist. These settings are discussed in detail in the Rock Your Groups guide.

Campuses

If your organization has several sites you can manage them here. See the chapter 'Campuses' to see the various options available to you.

Tags

Tags allow you to categorize people into groupings based on a descriptive label. Tags are discussed in detail in the Person and Family Field Manual. As an administrator, you will be responsible for the classification of organizational and personal tags. Only administrators can create an organizational tag or convert a personal tag to an organizational tag.

Workflow Configuration

Rock is built on top of a powerful workflow engine. These workflows can be configured using the screens found in this section. Creating and configuring workflows is covered in the Working With Workflows guide.

Workflow Triggers

You can configure a workflow to be launched whenever an entity record is changed or deleted. See the Working With Workflow guide for more information on configuring these triggers.

File Types

Rock can be made to store and manage several different types of files. These include things like images for marketing campaigns, label templates for check-in and the pictures of individuals that display on the Person Profile page. These files can be saved in different storage types. The two main storage types are:

• Database: The files are stored as BLOBs (Binary Large OBjects) in the database. Database storage is a good solution for items that you’d like backed-up with your data. Database storage is also a bit more secure since the files are stored in an additional layer of security in the database.
• File System: Files using this storage type are stored on the webserver’s file system. They are securely stored in a directory that cannot be directly linked to. This storage type is best for large files that might eat up your valuable database storage space.

Each file type can select which storage type to use. You can also specify if you would like to cache the file type to improve speed. Caching is especially useful when using storage types other than the file system since they tend to be a bit slower. Enabling the cache will store a cached version on the server to improve speed. Caching is also very useful when working with images. Rock has the ability to size images on the fly. While this is very powerful, it can impact performance, especially with large source images. When caching is enabled though, the resized image is cached, so the resize is not required in the future until the image is updated.

Named Locations

This configuration screen allows you to define specific locations with a name. You will want to use this to define your campuses, buildings and rooms. These Named Locations can then be used with configuring groups, check-in, etc.

Devices

The devices screens are used to manage devices that interact with Rock in some way. Today this is primarily used to help manage check-in kiosks but in the future we hope to add support for all types of devices.

Schedules

Several features require the configuration of repeating schedules. For instance, check-in needs to know your church’s service times to be able to configure the time check-in should start. These screens allow you to create these schedules.

Attribute Categories

Everything stored in Rock can have attributes added to it. For example, we can add numerous attributes to a person that match what is important to your organization. In an effort to keep this from becoming unmanageable, you can group your attributes into categories. These screens help define these categories and provide some basic configuration for each.

The first step in adding a category is to filter by the data entity you wish to work with. The default, and most often used, is Person. For each category you can provide a description and also give it an icon to use on the Rock screens.

Prayer Categories

The prayer features use categories to help organize and classify prayer requests. See the Raising Up Prayer guide for more information on configuring prayer features.

Person Attributes

This screen allows you to manage the person attributes you have configured in the system.

Person Profile Badges

Badges are simple icons that express details about a person’s involvement or activity with your organization. An example of a badge would be baptism or attendance rate.

Merge Templates

This is where you will managed the system wide merge templates. You can find out more about merge themplates in the Merge Documents chapter of this guide.

Group Requirement Types

This page allows you to managed the group requirements for your organization. You can learn more about group requirements in the Rock Your Groups guide.

Sites

The sites section lists all of the websites that are running off of your set-up of Rock. Rock initially comes configured with three different sites:

• Rock Internal: The internal site used by the organization’s staff to manage people and groups, and to manage the system in general.
• External Website: The primary portal for those outside the organization.
• Check-in: The site that is used for the check-in system.

You can add as many sites as you wish. For instance, the site that Spark Development Network uses to manage Rock has all of the sites above plus two additional ones. One hosts the Spark site (sparkdevnetwork.org) and the other hosts the Rock site (rockrms.com). Notice that each site looks different and unique from the outside, but shares a common set of data and configuration.

See the Designing and Building Websites Using Rock guide for more information on configuring new sites in Rock.

Block Types

Every page in Rock is made up of several blocks. These blocks are the core unit of functionality. You might be familiar with the HTML block on the homepage, for example. For the most part, everything on the screen is a part of one block or another. These screens list all of the various types of block available.

Page Map

While most of the configuration of a page can be completed right on that page, there are times when it’s difficult to navigate to a supporting page if it isn’t shown in the main navigation. This screen lists all of the pages defined in Rock in a simple tree display to help you get where you’re going.

Content Channel Types

Rock's dynamic content capabilties are a cornerstone of its content management system (CMS) feature set. The Content Channel Types helps to define the data structures for dynamic content. You can read more about these tools in the Communicating With Rock guide.

Content Channels

The Content Channels represent the actual data that is defined for use by the CMS tools. Again much more information on these tools can be found in the Communicating With Rock guide.

File Manager

The File Manager allows users to upload files and manage directories to the server that Rock is hosted on. More information on this tool can be found in the Designing and Building Websites Using Rock guide.

User Accounts

While you can find a specific user’s accounts on their Person Profile page, you can see a list of all user accounts on these screens. This helps determine which person is tied to a specific account and see the general login activity.

Security Roles

Security roles are used to lock down features and data in Rock. While you can configure Rock at the user-level (allow and deny specific users), it's much easier to assign people to roles and then base your security off of these groups. This adds consistency to your security model, which leads to fewer mistakes. The security role screens allow you to manage your roles and add individuals to them.

REST Controllers

One way you can build applications that extend Rock is through a technology called REST (REpresentational State Transfer, http://en.wikipedia.org/wiki/Representational_state_transfer). If this seems Greek to you, don’t worry. Most developers are familiar with it. The screens in this area help document all of the REST APIs that are available to you. From these screens you can also secure the REST API to ensure only authorized applications can access the data.

Audit Information

Most changes to the Rock database are tracked in a special audit table. The information in these tables is presented in the screens of this section. This is a helpful tool for you to see what changes are being made and by whom. You can also use these logs to write custom SQL reports or create custom jobs that take action after certain changes.

Entity Attributes

This configuration section can help you define additional Organizational Attributes. For the most part, you should not need to do this unless you are writing your own code to run inside Rock. To add an Organizational Attribute, simply create a new attribute that is not tied to an entity. (This really is what an organizational attribute is.)

By now you know about attributes and the power they bring to Rock. In fact, they are more powerful than you realize. We’ve already discussed how attributes can be attached to any type of entity (person, group, etc.) In more complex scenarios, you can actually attach them to an entity with certain criteria. Say you only wanted an attribute to be on a group if it is of the type Serving Team; you could configure that using these screens. Most organizations will never need to get this advanced with their configurations, but it’s good to know that it can be done, if needed.

Entity Administration

Entities are specific types of data. A person is a type of entity. So are a group, an email communication and a financial transaction. For those of you familiar with databases, an entity is like a table in your database. (In fact most, but not all, entities do have a corresponding table in the database.) These sets of screens allow you to view and configure all of the entities in Rock.

There are only two configuration items that you need to worry about. The first is whether the entity is "common." Common entities are shown at the top of the list when you need to select from a list of entities. Rock has preconfigured Groups and People to be common, but you may wish to add more (especially if you start adding custom entities of your own).

You can also add security to entities to help protect the data they contain. For instance, we have configured the Financial Transactions entity to only be viewable by those in the finance security roles. This is especially useful when it comes to using the reporting features of Rock. The security you define here will be used by the reporting engine to ensure that only authorized individuals are allowed to access sensitive data.

Authentication Services

Rock can be configured to allow several types of authentication during the login process. Let’s look at them more closely.

• Database: This is the most common authentication type for most organizations. This stores the user's username and password in the database. The user's password is stored in a one-way encrypted format so it cannot be retrieved by any means.
• Active Directory: If your organization uses a Microsoft Active Directory for network logins, Rock can use it to authenticate your staff. To enable this service, you will first need to activate it and provide the address of a Domain Controller server along with the Domain Name of your network. Then, you'll then be able to configure Active Directory logins for your staff under the Security tab on their Person Profile pages.
• PIN Authentication: This authentication service is primarily used in the Check-in Manager to provide a quick way to authenicate on touch devices. This authentication provide only requires a username made up of numbers.
• Facebook: You can also enable the use of an individual's Facebook account as authentication to Rock. This makes their life a little easier when they have one less password to remember. In order to enable this, you will need to configure a Facebook application.
• Google: This authentication provide allows guests to use their Google account with Rock.
• Twitter: As you can probably guess... yes, you can use Twitter as an authentication source.

REST Keys

When writing applications that use Rock's REST API you will need to use keys for authentication. These keys can be setup and configured here. See Rock's developer documentation for more information on using REST keys in your applications.

REST CORS Domains

Writing secure web applications requires that all domains that use your server's REST API be authorized using Cross-Origin Resource Sharing (CORS). You can define these allowed domains here.

Communication Templates

You'll find over time that you often send the same types of emails and SMS messages over and over. When you see this pattern consider making a communication template to help simplify these tasks and improve consistency.

System Emails

Rock defines several email templates that are used by the system for specific needs. Some examples are the emails that are sent when someone forgets a password or a confirmation message when an account is created. You may want to change the look or wording of the emails to better match the brand and voice of your organization. This is the place to do so.

Communication Mediums

When you send a new communication from Tools > New Communication or from the bottom of any grid that contains a list of people, you can select to send either an SMS message or an email. Each of these are communication mediums. You can configure the settings for each medium from these screens. This is where you can set the Email transport to use normal SMTP or a bulk delivery service like SendGrid. This is also where you can configure the SMS channel to use Twillio to send the messages.

Rock is powerful because of its customization possibilities. Here, you can add additional communication mediums. For example, it’s possible that in the future a new medium might be created to push content through an organization's mobile app. Once this new medium is written (by either a third-party or the core team), it can be simply dropped into Rock and worked by using configuration from these screens.

Communication Transports

We mentioned services like SendGrid, Twillio and SMTP above in the Communications Mediums section. These delivery options are called Transports. They are what take the message contents and make sure that they get to the recipients. Each has a set of configuration options specific to its needs. For example, the Twillio transport requires an account SID and a token to tie into your account. These settings can be provided using these screens.

Like channels, new transports can easily be added over time, from either the core Rock team or third parties.

SMS From Values

This menu item is a hotlink to the SMS From Values defined type. This defined type helps you configure the SMS environment. See the Communicating With Rock guide for more information on SMS.

Safe Sender Domains

This menu item is a hotlink to the Safe Sender Domains defined type. This defined type defines the domains that can be used to send emails. If an Email communication is created with a From Address that is not from one of these domains, the Organization Email global attribute value will be used instead for the From Address and the original value will be used as the Reply To address. This is to help reduce the likelihood of communications being rejected by the receiving email servers.

Photo Request

These pages allow you to send and administrate requests for photos from your community. You can find detailed instructions for these tools in the Person & Family Field Guide.

System Email Categories

This page allows you to create and manage categories for your system emails.

Check-in Configuration

These screens help manage the setup of your check-in configurations. These settings are discussed in detail in the Checking-out Check-in guide.

Named Locations

This configuration screen allows you to define specific locations with a name. You will want to use this to define your campuses, buildings and rooms. These Named Locations can then be used with configuring groups, check-in, etc.

Also available under Admin Tools > General Settings > Named Locations

Schedules

Several features require the configuration of repeating schedules. For instance, check-in needs to know your church’s service times to be able to configure the time check-in should start. These screens allow you to create these schedules.

Also available under Admin Tools > General Settings > Schedules

Devices

The devices screens are used to manage devices that interact with Rock in some way. Today this is primarily used to help manage check-in kiosks but in the future we hope to add support for all types of devices.

Also available under Admin Tools > General Settings > Devices

Check-in Labels

The check-in process can be configured to use several formats of printed labels. These labels and their configuration are managed using these screens. The Checking-Out Check-in guide also covers the creation and configuration of these labels.

Ability Levels

This is a short-cut link to the Ability Levels defined type. Also available under Admin Tools > General Settings > Defined Types > Ability Levels

Label Merge Fields

This is a short-cut link to the Label Merge Fields defined type. Also available under Admin Tools > General Settings > Defined Types > Label Merge Fields

Search Types

This is a short-cut link to the Search Types defined type. Also available under Admin Tools > General Settings > Defined Types > Search Types

Using a Merge Document

You'll notice at the bottom of most grids there's a button that looks similar to . Pressing this button will take the contents of the grid and make it available to import into a merge document.

1 Count

Shows you how many records will be merged into the document.

2 Combine Family Members

When checked family members will be combined into a single row. For example, when using {{ Row.NickName }} Ted Decker and Cindy Decker would be combined into 'Ted & Cindy'. NOTE: Design your template to use {{ Row.FullName }} instead of {{ Row.NickName }} {{ Row.LastName }} to help in situations where family members might have different last names.

3 Show Data Rows

Shows the first 15 records that will be used for the merge.

4 Show Merge Fields

This is a cheat sheet of sorts to help you create a merge document for the data provided.

5 Merge Template

The template to use for the merge document.

6 Merge

This button will initiate the merge process.

That’s it! Pretty easy, no?

Administrating Merge Templates

Merge documents are created from templates. Some merge templates will be used by everyone, others though can be limited to a specific role or person. To help keep the list of merge documents from getting out of hand, we’ve created the ability to define global templates and personal templates.

Global Merge Templates

You can set up a list of merge templates that are accessible to everyone in the database under Admin Tools > General Settings > Merge Templates.

Personal Merge Templates

You can set up a merge document for your personal usage under on your My Settings page (this is found under the dropdown in the upper-right corner of the screen).

Creating a Merge Document

Rock currently supports two different merge document formats: HTML and Word. Below we cover how to create a merge document for each format.

Word

The most common document format is Word. Creating these documents is actually pretty simple. Before we jump in it's important to talk about the two strategies for merging using Word.

The first strategy is to create a Word document where the whole document acts as a template for each record. This is most common for things like letters.

With this type of document you can simply open Word, type your letter and then add in the Lava where you want the dynamic text to show. Note that you have access to most of Lava's capabilities in Word. So things like {{ 'Now' | Date:' MMMM d, yyyy ' }} will place in the current data time.

The second merge document strategy is for occasions where you want more than one record to be displayed on a single page. This is often the case for tasks like creating mailing labels. When creating these types of documents you add a {%Next%} code when you’re ready to move to the next record in the list.

Rock will automatically figure out what strategy your document is using so there is no extra configuration.

HTML

You might be wondering, "Why would I ever want to use HTML for a merge document?" At first blush it does seem a little odd. HTML however is a great tool for incorporating rich media into a format that can easily be printed. It’s often the best choice when you need to print a report that requires showing maps (easy to display using Google's static map API) or person photos (links to their photo in Rock).

Creating an HTML merge document is simple. Let's take a quick look. Below is a quick example of some HTML/Lava that will present a list of people with their photos (this assumes that the merge document is passed a list of people).

<html>
    <head>
		<title>Group Roster</title>
		<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.5/css/bootstrap.min.css">
	</head>
	
	<body>
	    <div class="container" style="margin-top: 100px">
			<div class="row">
			    
				{% for row in Rows %}
					<div class="col-xs-6 clearfix" style="margin-bottom: 24px; min-height: 200px;">
						<div class="pull-left" style="margin-right: 24px; width:20%;">
							<img src="{{ 'Global' | Attribute:'PublicApplicationRoot' }}{{ row.PhotoUrl }}" style="width: 100%; border-radius: 100px;" />
						</div>
						<div class="pull-left">
							<h1>{{ row.FullName }}</h1>
							{{ row.Email }} <br />
							{% for phone in row.PhoneNumbers %}
								{{ phone.NumberFormatted }} <small>{{ phone.NumberTypeValue.Value }}</small> <br />
							{% endfor %}
						</div>
					</div>
				{% endfor %}
				
			</div>
		</div>
	</body>
</html>

Note a few things in the code.

• Line 4: We link out to a hosted version of the Bootstrap CSS file. This provides an easy way to get a default set of styles.
• Line 11: Now we simply run through each of the rows that were passed to us.
• Line 14: Inserting a photo is simple! The PhotoUrl property for a person even returns a blank image if the person doesn’t have a photo.

As you can see, creating HTML merge documents is easy. Here are a few additional tips:

• Adding map images to your merge documents is also fairly simple. Use the following links for more information:
  • Google Maps API
  • Static Map Helper
• HTML merge documents are usually printed. While most people think of HTML as an online-only file format, it actually does have several print capabilities like page-breaks. Here are a few links to point you in the right direction:
  • Styling for Print
  • CSS Page Breaks

SQL Command

The SQL Command page is very powerful, but should be used with great caution. Rock is built on top of Microsoft’s SQL Server database. While for most people, this is a detail they don’t need to know, at times administrators may want to type in a SQL command to get direct access to their data.

The SQL Command block allows you to type in a SQL command and have it execute directly in the database. When used with a SELECT command, the results of your query will be displayed in a grid below the command.

You can also enter in UPDATE and DELETE commands, if you wish. In order for them to work, you’ll need to flip the Selection Query toggle as an additional fail-safe.

External Applications

We've worked hard to make as much of Rock available through a web interface as possible. Some functionality, though, requires interaction with devices like check scanners (which don’t work through today’s web browsers). Other times there are situations, like creating giving statements, where the processing of a request could take awhile to complete. In these cases, we’ve developed Windows applications to run on your desktop. These applications can be downloaded from the links provided in this section.

Sample Data

When you're just starting out, it's helpful to have some sample data to play with. Or, perhaps you'd like to create a training environment for teaching your staff. Either way, adding a standard set of people, families and groups is a breeze with Rock.

The Sample Data block is a one-step way to import a consistent set of sample data. You'll recognize many of the names from the examples in the Rock documentation. Free free to run the import repeatedly to keep time-sensitive data like attendance current.

Geocoding Services

Knowing the location of those who attend your church can be very powerful. In order to do this, you need to be able to convert an attendee's address (3120 W Cholla St Phoenix, AZ 85029) to a latitude / longitude point (33.590795 , -112.126459). To do this you’ll need to run your addresses through a geocoding process. Rock will handle all of the work. All you need to do is provide a geocoding service to handle the requests. Rock has a couple of services for you to pick from. More information on geocoding can be found in the Locations Section of this document.

Standardization Services

Similar to the geocoding services, you can also send your addresses through a standardization process. These processes can fix the following for your addresses:

• Fill in any missing items (555 W Main to 555 W Main St)
• Fix any case issues (555 w main st to 555 W Main St)
• Standardize elements (555 West Main Street to 555 W Main St)
• Append Zip+4 info (85383 to 85383-3622)

The standardization process helps increase the quality of the addresses in your database. More information on address standardization can be found in the Locations Section of this document.

Search Services

Rock’s Smart Search box at the top of every page allows you to search for people and groups using various criteria like name, phone and email. These screens allow you to manage these search types. For the most part you’ll want to leave them set as-is but you can inactivate one if you find it is not helpful in your situation. A key concept is that you can write your own search services with some custom coding. If you do, they will appear on this list for you to enable and configure.

Jobs Administration

While much of Rock works through the interaction of individuals within the system, there are times when you’ll want to run functionality in the background. Examples of this might be some clean-up of the database or updating of data in the database. These background tasks are called Jobs and can be managed and scheduled through the screens in this area. More details on jobs can be found below.

Data Filters

Data Filters are an integral part of Rock’s reporting strategy. Hopefully you’ve already read about them in the Taking Off With Reporting guide. At a high level, data filters allow you to narrow down your view of data by providing specific criteria. These filters can be enabled, disabled and secured in this set of screens. Like many things in Rock, you can develop your own Data Filters that can be managed here.

Data Transformations

Once you’ve filtered your data, you can add a transformation to it before it is displayed. Say you filtered to see only children who have attended twice in the last two months, but you really want to display information about the parents of these children. A transformation (in this case the Person Parent Transformation) would convert the child data to parent data. You can manage these transformations here. Just like with filters, you can also develop your own transformations.

Data Selects

Data selects are used in reporting. When you create a report, you provide it with a data view to act as a filter. You also add columns to your report. Many of these columns will be attributes of the person or group. You can also choose to add some powerful dynamic columns. These dynamic columns are managed and secured from this screen.

Exception List

Errors are a fact of life. Some errors are the result of bugs in the software. Despite all of our work to eliminate bugs, some will sneak by us. Exceptions can also occur when blocks and pages are misconfigured. While you can set these errors to be emailed to you under the General Settings > Global Settings > Email Exceptions List, you can also view the history of these errors here.

Exceptions are shown in the order they occur. Instead of showing you every error in a large list, we have grouped them by type. This helps you determine how often an error is occurring.

Protect My Ministry

Rock provides a seamless integration with Protect My Ministry to provide reliable background checks for your organization. See the Background Checks chapter below for specifics on this integration.

File Storage Providers

Under the Admin Tools > General Settings > File Types section we discussed file storage providers. These providers help Rock manage the saving and retrieving of files to different storage mediums. The two default storage types are Database and File System. Under the File System configuration you can change the default location for files storage. For the most part, you can leave these settings as you found them.

Financial Gateways

Financial gateways allow Rock to move money from individuals’ accounts to the organization. Information on these gateways and their configuration are discussed in detail in the Rock Solid Finances guide.

History Categories

Similar to the audit functionality, is the concept of History. While the audit feature shows nearly every change made in the system, History only shows certain changes that we’ve determined are important.

This section of the System Configuration allows you to create categories for history types. This helps coordinate history changes into related groups. For the most part, you will not need to change these categories.

System Configuration

This screen allows you to change some technical configuration settings of Rock. For the most part you should never need to worry about these settings, but we have provided this screen to help you change these settings if needed. Each of the settings is discussed below.

• Time Zone: During the install you should have set your time zone. If you need to change it, you can do that here.
• Max Upload File Size: For security reasons, webservers limit the maximum file size that can be uploaded. This helps to limit the impact of denial of service attacks. Rock has set the default value to 10 MB. If you need more you can update the size here.
• Run Jobs In IIS: By default, Rock’s job engine runs on the webserver. This setting allows you to disable this in order to run jobs as a Windows Agent. See the Jobs section for more information on this topic.

Application Groups

Several features in Rock rely on storing information on people. For instance when you use the photo request feature, Rock needs to track who has uploaded a photo, who's photo needs to be verified and who has opted-out of getting future requests. Instead of writing tons of custom code to do this we've chosen to create a re-usable group type called Application Groups. These groups are listed here for administrator access.

Background Check Providers

These screens allow you to configure different background check providers. You can read more about Rock's background check feaures in the Person & Family Field Guide.

Merge Template Types

Rock allows you to have several different merge template types (think 'HTML', 'Word', etc.) You can manage these provider types with these screens.

Note Types Settings

Rock allows any entity type (People, Financial Batches, Prayer Requests, etc.) to have notes attached to them. In fact it even goes further to allow different types of notes on a single entity. These screens allow you to setup this powerful feature. You can read more about these features in the Note Types chapter of this manual.

Following Events

This section allows you to define new Following Events. You can read more about these features in the Person & Family Field Guide

Following Suggestions

This section allows you to define new Following Suggestions. You can read more about these features in the Person & Family Field Guide

Managing Your Campuses

You can manage your campuses from Admin Tools > General Settings > Campuses. There you will see a list of campuses that you can manage or add to. Selecting a campus will bring up the campus details screen.

1 Name

The name of the campus.

2 Active

As you bring new campuses online, you may want to add them as inactive until you have time to configure them and prepare for the announcement.

3 Description

You can use this field to provide a description for your campus. This might be something you display to your website guests.

4 Short Code

When you grow beyond two or three sites, it's common to develop a shorter naming convention to help you refer to a campus.

5 URL

The web address for the campus.

6 Campus Leader

The person placed in charge of running the campus.

7 Contact Information

The phone number and address of the campus.

8 Service Times

The servcie times for the campus.

Adding Attributes to Campuses

There are probably other bits of information you'd like to track about your campuses. Adding additional Attributes to campuses is simple. Just follow these steps:

1. Go to Admin Tools > Security > Entity Attributes.
2. Click the to add a new attribute.
3. Select the Entity Type of "Campus" and set up the attribute information. You do not need to add a value for the Qualifier Field or Qualifier Value fields.
4. After clicking Save, you can configure security on who can edit this attribute if you wish.
5. You will now be able to set a value for this attribute in the campus details page above.

Configuring a Job

You can change the configuration of a current job or add a new job under Admin Tools > System Tools > Jobs Administration. There you will see a list of currently configured jobs. You can click a job to modify the configuration or click the Add button in the grid footer to create a new job.

After you select to add or configure a job you’ll see the screen below.

1Name

Provides a concise description of what the job is doing.

2Active

Allows you to mark the job active or inactive.

3Description

Documents in detail what that job is doing and any background criteria that you may want to know in the future. Use this field to document all the details about the job.

4Notification Status

Defines when a notification email should be sent. Options are: Success – when a job finishes successfully; Error – when a job encounters an error; All – for both Success and Error; None – never

5Cron Expression

Defines when the job is run. Cron expressions are a concise schedule pattern. They can be difficult to write without help. We recommend using the CronMaker.com website to assist you in creating these expressions.

6Notification Emails

A comma separated list of emails for the job; to use when a notification needs to be sent.

7Job Type

Selects the type of job to run.

8Job Settings

Each job type will have a set of configuration items. In this sample, the RunSQL job defines the SQL statement that you want to run when the job executes.

Under the Hood of the Jobs Engine

By default, the jobs engine runs on the webserver under the IIS webservers context. By default, IIS will shut down if no requests come in for a page. This will mean that your jobs may not execute late at night if no one is visiting your site. To mitigate this problem we created a special Job Pulse job that is set to run every 30 seconds. Its only purpose is to load a special KeepAlive.aspx page. Doing so keeps IIS alive at all times.

Large or complex organization may wish to run their jobs in a more robust fashion. For these situations, Rock can be configured to run the jobs engine as a Windows service. This requires some special configuration. We have outlined the steps required to configure this below.

Steps to Setup Rock to Run Jobs as a Windows Service

1. Edit your web.config by setting the appSetting RunJobsInIISContext to false.
2. Install the Rock Jobs Windows Service on a machine with access to the Rock database. The installer for this can be downloaded from Admin Tools > Power Tools > External Applications.
3. Changing the service's Log On As to Local System.
4. You will need to create a connection string file in the folder that you installed the Rock Job Service to. This file should be named 'web.connections.config'. The contents of this file should be that same as the one inside your website root directory. You may need to adjust the database server name depending on your environment (for instance if the database is installed on your webserver the server name maybe localhost).
5. Start the Rock Jobs Windows Service.

Adding Notes to a New Entity

Let's say your finance team asks you to be able to enter notes on batches. Your first response might be that you'll have to find a developer to add that functionality. That in itself is a pretty cool option...right? The fact that you have a system that you can extend to meet any need...cool! But in this case you can play the part of the hero (that is the name of this guide remember) and configure it yourself.

Any entity detail page is a candidate for adding notes. Looking at the address for the page will tell you which entity you can attach the note on. If the address has BatchId=X then the note can be on the batch entity. Let's walk through the steps of adding notes to the batch detail page Finance > Batches > Batch Detail.

1. Once you’re on the batch detail page, add a new Core > Note block to the main zone (see the Designing and Building Websites Using Rock for details).
2. Edit the block settings of this new block. There are several possible configurations so look through the list. The key, however, is setting the Context Entity Type to be Financial Batch.
3. Reload the page for the block settings to be enabled. You should now see an empty note block.
4. The last step is to add the note type under Admin Tools > System Settings > Note Types. You can add a note type from the bottom of the grid. Be sure to set the entity to Financial Batch.

After following these steps your batch screen should look something like the one below.

Adding Multiple Note Types to a Single Entity

When you add a note to a person on the Person Profile page you are adding a generic Person Note to the person entity. What if you wanted to be able to add a new type of note to a person? Say for instance your organization has a hospital visitation team and they want to have their own notes that stand out from the default ones. Developer needed...? Nope! You got this. Let's walk through the steps of adding this new Hospital Visitation note type.

The first step is to add the new note type under Admin Tools > System Settings > Note Types. From the bottom of the grid select the Add button and the new type modal will be displayed.

1 Name

The name of the note type that will be used in the various input screens.

2 Entity Type

The type of oject/entity the note is for. In this case the note is for an individual so we'll select Person.

3 User Selectable

This flag enabled the note type to be selected from the note entry screen. There are times when you won't want a certain type of note to be selected through the user interface. Other note types may only be added through workflows or custom code.

4 CSS Class

This is the CSS class that will be added to the note when displayed on the screen. This allows you to customize the color and styling of the note. Rock comes with several general classes built in to assist you. These include:

• Note-danger (red)
• Note-success (green)
• Note-info (blue)
• Note-warning (yellow)

5 Icon CSS Class

This is the icon to display next to the note.

Once your new note type has been defined it's ready to be used. At this point you may consider adding security to it to control who has access to view and edit these notes.

Active Directory

Many organizations already have a Microsoft Active Directory (AD) infrastructure in place for their employees to log into the network, email and other resources. Rock can use this as an additional authentication source once configured.

You can setup Rock to use your Active Directory under Admin Tools > Security > Authentication Services > Active Directory

1

Be sure to activate the security service.

2

2. Provide the server name of one of your Active Directory Domain Controllers.

3

3. Configure the AD Domain on the server to authenticate to.

Once the service is configured, you're ready to create logins in Rock. Active Directory logins can't use the normal Rock registration process. Instead you must add the login manually to the user on the Person Profile page.

Facebook Authentication

Password fatigue is a common problem with sites that require registration. In fact, a recent study found that 92% of shoppers abandon a website rather than go through the process of recovering a lost or forgotten password! However, if the website has a social media login option, they are 65% more likely to return. The same study showed that a majority of users prefer Facebook as their credential of choice. Luckily setting up a Rock website to use Facebook authentication is quick and easy. Simply follow these steps.

1. The first step is to visit the Facebook Developer website (https://developers.facebook.com/apps) and create a new application. When you do this you might consider creating a login for your organization, rather than linking it to your personal Facebook account.
2. At the top of the screen click Add a New App, choose a display name for your app your users will recognise, pick a relevant category, and add an appropiate logo. This logo will be show to your users when they authenticate, so be sure to use an organization logo that they will recognize and trust.
3. Then on the left hand side click Settings and
4. Select Add Platform, choose Website, and enter in your site URL in the box that appears.
5. In the sidebar, Click on Settings and then select the Advanced tab.
6. In the Client OAuth Settings section, enter the URL for your site in the "Valid OAuth redirect URIs" field. You MUST include the port your website runs on (default is 80) such as http://rocksolidchurch.org:80/ (Note: Only the Web OAuth Login needs to be enabled in this section.) Click Save Changes when finished.
7. Now, the new application's "App ID" and "App Secret" add these values to the Facebook Services configuration under Admin Tools > Security > Authentication Services > Facebook.
8. Finally, be sure to make the app public. First Click App Review in the left menu panel. Then click the slider to On under Make {{ app name }} Public. (Note that the URLs behind an SSL are on port 443.)

Facebook is now activated and ready to be used. You can now enable it on each of your login pages by setting the block settings of the login control to enable the "Facebook" external service provider. Having this block setting allows you to decide which of your websites allow Facebook to be used (some organizations may prefer not to allow Facebook to be used to login to their internal Rock site.) Once enabled your login screen will now have an additional button to allow individuals to login using their Facebook account.

When someone logs in using Facebook they will see a screen similar to the one below that links their Facebook account to your server.

When an individual's Facebook account is used for the first time Rock will apply the following logic to attempt to match the Facebook account to a Rock record.

1. If a person record can be found with the same First Name, Last Name and Email, the login is attached to this record. As an extra bonus, if no birthdate is in Rock for this person the birthdate from Facebook will be added to the person’s record in Rock.
2. If an exact match could not be made, a new Rock record is created using the information from their Facebook account. The record status of this new individual is set to "Pending" so they will show up under the "Pending Individuals" report Tools > Reports > Data Quality > Pending Individuals.

Google Authentication

With the popularity of Gmail, Google authentication is an attractive alternative for many guests. Below are the steps necessary for Rock to use your guests' Google passwords for authentication.

1. Visit console.developers.google.com/start and create a new project for your organization. If you already have a Google Maps API key, then you will want to use that project.
2. On the left hand of the screen expand the APIs and auth menu, click on the Credentials, and at the top of the screen click on OAuth consent screen.
3. Fill out this screen with your organization’s information. The information given here will be presented to your users when they sign in for the first time. A preview of the screen your users will see should be on the righthand side of your screen. You’ll want to include branding that your users will recognize and trust.
4. At the top of the screen click on the Credentials tab then click on the Add Credentials dropdown, select OAuth 2.0 client ID, and then select Web Application.
5. Under Authorized redirect URLs, you'll need to place the full URL of all of the login pages you configure to use Google authentication. For example, http://rock.rocksolidchurch.com/page/3 for the internal site. When you've finished adding URLs click Create.
6. You should be presented with a Client ID and a Client Secret. Note these values and add them to the Google service configuration under Admin Tools > Security > Authentication Services > Google.

Twitter Authentication

Rounding out the list of popular sites to use for authentication, we also support Twitter. The directions below will get you up and running quickly.

1. Visit apps.twitter.com and create a new app for your organization.
2. Give your app a name and a description. This will appear to your users, so make it recognizable. Also put in your organization's forward facing website URL, and in the callback URL field put the URL for your primary login page. This will be overridden but the callback URL field needs to have a value for the authentication service to work (for example: http://rock.rocksolidchurch.com/page/3). Click Create.
3. Navigate to the Keys and Access Tokens tab at the top and note the Consumer Key and Consumer Secret values. Add these to the Twitter service configuration under Admin Tools > Security > Authentication Services > Twitter.
4. In order for your application to connect Rock user accounts to Twitter accounts, you need to request elevated permission for your application to access email information associated with Twitter accounts. You can do this via this link https://support.twitter.com/forms/platform and select the I need access to special permissions option.

Phone Numbers

Post install, Rock is configured to support only US-formatted phone numbers. When only one country is configured, the phone entry field looks like the example below.

This field can easily be adjusted to support other countries. Simply add country specific formatting fields to the Admin Tools > General Settings > Defined Types > Phone Country Code defined type.

Each new entry should have the following values.

• Value: This is the country code that is used when dialing the number
• Description: A short description of the phone formatting pattern
• Match Expression: This is a regular expression that is used to match the value you entered and apply the correct formatting to it. For instance a seven-digit number in the US would match the formatting rule 555-5555 while a 10 digit number would match to (555) 555-5555.
• Formatting Expression: This string is used to apply the formatting to the matched number. Each grouping of numbers is represented by a $#.

Once you add a second country, the phone number field will change a bit in look. You will notice the addition of a country code selection at the beginning of the input. The phone country code listed at the top of the defined type list will become the default country code.

Dates & Times

We believe the .Net framework that Rock is built on should handle the formatting of dates and times correctly across regions. If you find an area of Rock that shows a date and/or time in a US format, please let us know by opening a Rock issue. Before opening a request, be sure to check the server's culture setting. This can be found on the ‘System Information’ dialog access from the Admin Toolbox at the bottom of each page.

Currency

There really isn't any magic in Rock’s implementation of local currencies. Behind the scenes, currency is stored simply as a number. You can change the currency symbol displayed within the application under Admin Tools > General Settings > Global Attributes > Currency Symbol.

International Address Support

By default, Rock is set to accept and display US-formatted addresses. For most organizations operating inside the US, this will be the preferred configuration. Enabling support for international addresses is simple and remarkably powerful. Let’s take a look.

School Grades

Rock provides a customizable system for determining the grade / year an individual is in their education. You can read more about how this grade system works in the Person & Family Field Guide.

Strategies for Full Localization

Full localization, including the support of multiple languages, is outside of the scope of the Rock project. However, it is possible for someone to fork Rock's source and localize the code and database contents. If you are interested in starting an internationalized port let us know and we'd be happy to help share your work.

What To Do When Rock Won't Load

You make a configuration change and next thing you know Rock's not loading any longer. What should you do?! First, relax. A calm mind will lead to a quicker resolution while stress might only dig you in deeper. Here are some things you should try first.

SELECT TOP 100 *
  FROM [ExceptionLog]
  ORDER BY [CreatedDateTime] DESC                    
                

Caching

Rock uses a very sophisticated and fast caching sub-system. The cache greatly reduces the need to read from the database. Tuning this cache is so important to us that we even show the Cache Hit Ratio in the bottom admin bar. The good news is Rock's cache is VERY fast as it uses the server's memory. Unfortunately, it makes running on multiple servers somewhat difficult. How? Let's walk through an example.

Say you're running two Rock servers A and B. While connected to server A you make some security edits. These edits are updated in the database and in server A's cache. Unfortunately, the original security settings are also in server B's cache and he has no idea they've been updated. So what's an admin to do? Well, we have you covered!

Redis to the rescue! Redis is a very fast NOSQL database that many large websites use to increase performance. Redis has two features that make it a great solution. The first is the NOSQL database. Many people use the Redis database for caching. The second feature is a messaging system that allows you to publish and receive small messages. Think of it as a chat room of sorts. Because Rock's in-memory cache is so fast, the architects decided not to use the Redis database. Instead, when enabled, Rock servers can use Redis to share when they update or flush their cache. If you think back to the chat room analogy, think of the servers as connecting to the chat room to send messages to each other whenever they update their cache. Pretty simple right?

Let's walk through how you can setup multiple Rock servers.

1. Install a Redis server on your network. Because Rock doesn’t use it for storing cache, it doesn't need to be a beefy sever, but it should be reliable and always on. See the Redis for more information on the various server options available. Since Redis is open source, many free options are available. If you’re mainly a Windows shop you should consider using the Microsoft Redis server available at: https://github.com/MSOpenTech/redis/releases. It is recommended that you use the 3.x version of this server.
2. Install your Rock websites. Be sure that the same versions of Rock are installed on each server and that they use the same web.config. Each install of Rock has its own encryption keys located in the web.config. These keys must be the same on each server.
3. OK, we said the web.config files should match… except for one small setting. Be sure that only one of your servers has the RunJobsInIISContext setting set to true. Running the Rock jobs on two servers at once can lead to some interesting (read: bad) situations.
4. To enable the Redis caching notifications you'll need to set the EnableRedisCacheCluster setting to true in the web.config. You'll also need to set the RedisConnectionString to point to your Redis server. An example of this connection string would be redis.rocksolidchurchdemo.com:6379.

Rock Jobs Engine

By default, the Rock Job engine runs inside of the IIS context. For scaling purposes, you may wish to run it as a Windows service on a different server. See the Jobs chapter for more information on configuring the job engine to run as a Windows service.

Inital Slow Response Times

Here's the scoop on slow initial Rock load times. Rock uses a database access technology call Entity Framework (EF). On first load (the very first page that's started when the application loads) it can take a few seconds for EF to check the database to see if any changes are required. Subsequent pages will load much faster. You will notice that once a page loads the second load of that page is super-fast. That’s Rock’s caching engine kicking it. So that's all fine and good until…

IIS's AppPools (think of it as the engine that powers Rock) need to be refreshed on occasion. By default this happens every 29 hours ( you should reset yours to always occur at a specific time, like 1am). When the AppPool recycles the whole EF start up happens again. For more information on configuring the AppPool see this blog post.

We'd recommend that you use an HTTP status tool like Pingdom to constantly poll your site. Not only will this notify you went it's down, but it will also be the first to load your page after a AppPool recycle.

Once Rock is started there is an internal keep alive process to ensure your site doesn't go into a sleep like mode. Once the initial page is loaded this process will ensure Rock stays awake and responsive.