Group Maps

Clicking the map marker button will take you to an interactive group map showing the members of the group. Depending on the configuration of the group other features may be enabled.

If the group has a geopoint (determined through the address geocoding process or by selecting the point on the map) the location of the group will also be present on the map.

If the group has a defined geofence this fence will be shown on the map. The presence of the geofence will also enable the display of connection status checkboxes at the top of the map. Checking these boxes will show everyone with that connection status in the database who lives within the geofence. This allows you to view possible 'prospect' group members.

Adding a Group

You can add a new group to the tree by clicking the Add Group dropdown and then selecting the location from the list. Adding a group to the Top-Level will place the group at the root or top of the tree. Selecting Child to Selected will place the group under the currently selected group.

Group Details

The group details section displays all of the information about the group. The group type and campus (if configured) will be shown as labels in the banner at the top. A map of the group’s location will also be shown, if configured.

Editing a Group

Clicking the Edit button from the detail section will allow you to edit information about the group and provide additional configuration settings. From here you can also change the group name and set whether a group should be active or inactive. If you mark a group inactive you also change the active status of all child groups to inactive as well. Each area of the edit screen is discussed below.

Group Hierarchy

One of the most important concepts to understand as you create new group types is the relationship that groups have to each other. There are two basic hierarchy types to choose from:

• Structured Hierarchy: In this configuration, the levels of hierarchy are defined and limited. For example, you may want to define the hierarchy of your small group ministry to have a single leadership team, under them a level of lay leaders who act as coaches to the groups, and then the groups themselves. In a structured hierarchy you can be sure that this structure is enforced.

  

• Flexible Hierarchy: For some ministry types, you want your groups to have a more unstructured hierarchy. An example of this might be how you set up serving teams. You may want serving teams to be able to have sub-teams that might have additional sub-teams themselves. These hierarchies may be very deep in some ministry areas (like First Impressions) but shallow in others.

  

You define these hierarchies by configuring what child groups each group type can have. In the structured example, you would create a group type called Small Group Leadership, which would allow child group types of Group Coaches, which would allow child groups of Small Groups. The Small Groups would not allow any child types, ensuring that your hierarchy was fixed at the third level.

In the flexible hierarchy example, you would configure Serving Teams to have child-types of itself. This guarantees that you can have an unlimited hierarchy.

Administering Group Types

You administrate group types under Admin Tools > General Settings > Group Types. When adding or modifying a group type, you can provide the following types of configuration:

Let's look at the different Group Types settings you can configure in the Group Type Detail block.

Group Member Roles

People often have special roles in groups. Some are leaders; others have unique duties. To help differentiate the members of a group, you can give each a Group Member Role. The list of possible roles are defined on the group type. For more information on the roles available, you can check out the chapter on Group Members.

Securing Group Types

By adding security to a group type, you control the base security of every group of that type. Let's say your organization adds a new type of group to help manage some classes you're starting. You may want to create a new group type for this initiative where every class is a group of this new type. By adding security to the group type, you can ensure that every group can be viewed and edited by a select handful of people.

To add security to a group type, go to Admin Tools > General Settings > Group Types. There you will see a list of group types in a table. In the far right column you will see an button. Clicking this will allow you to set the security for the selected group type.

Securing A Group

There may be occasions where each group will need different security settings. Don't worry, this is super easy in Rock. To secure a specific group, find the group in the group viewer (People > Group Viewer). On the group details page you'll find the same button. Clicking this button will bring up the Rock security dialog where you can adjust the security settings. Anyone with permission to edit security roles also has access to the Manage Members tab, where they can add, edit and delete group members (but not edit or delete the group itself).

Note the inherited permissions at the bottom of this screen. Inherited security is a very powerful concept with groups. By default, a group will inherit the security of its parent groups and group type. This limits the amount of security configuration each group requires. These inherited rights are only a starting point. You can either build on top of these permissions or override them. The choice, and power, is up to you.

At first you may be tempted to go overboard with your group's security settings. In general it's best to keep them simple. For instance, in the case of home-based Bible studies you may be tempted to secure each group differently to only allow the leader to edit them. While in certain cases you may need to do this, you could also secure all groups with a generic Small Group Leader role. You could then limit which groups a leader was able to navigate to through the configuration of your leader toolbox blocks.

Group Member Roles

Group member roles play an important role in how groups are secured. Each role can be configured to provide View and / or Edit rights. This is configured under Admin Tools > General Settings > Group Types.

Inherited Permissions

When determining the security of a group it’s important to consider not only the specific permissions of the group but also the inherited permission rules. The inheritance rules for groups is:

Current Group > Group Type Security > Parent Group Security > (continue up the hierarchy till it reaches the root group) > Group EntityType Security > Global Default.

The primary inheritance rules come from the group’s hierarchy but the system has a built in ‘choke point’ check on the security of the group type first. Why is this? Adding a quick check of the group types security allows specific types of groups to have unique security considerations. Take for example a group type for ‘Addiction Classes’. Adding a check for the group types security allows a way for limiting visibility to these groups without having to worry about inconsistencies in the security of the group hierarchy. In most cases the group type will not have specific security so this check will not matter, but it’s there if you need it.

If when checking the group’s security the person is blocked access there’s still one last check to be done. Roles defined on the group type can be configured to provide access to the group. For instance you can configure the leader of a group to have view/edit rights to that group. Likewise the member of a group could be setup to have view access. This allows a very simple and flexible way of providing access to external individuals.

Multiple Group Viewers

Rock comes preconfigured with a general group viewer People > Group Viewer, but you can add more. Say, for instance, your church has a strong small group ministry. You may want to create a new Group Viewer page just for this ministry. You can do this by adding a new page under People (or any other page you like) and add the group viewer blocks to the page.

The following blocks are used to make a group viewer. We recommend that you use the LeftSidebar Panel page layout.

1 Group Tree View

Add a group tree view block to the sidebar zone to help you navigate your group heirarchy.

2 Group Details

Add the group details block to the top of the main zone.

3 Group Member List

Next add the group member list block under the group details.

When you set up the Group Tree Block you can set the root group to start with and limit which types of groups it will display. This allows you to make a very specific small groups viewer with just a couple of clicks.

Group Folders

As you start to think about your group hierarchies, make sure that you plan for growth. This might mean that you create special groups in your hierarchy to help to categorize your groups. You can think of this like using folders on your computer to help manage all of your files. You could throw all of your files in one folder, but you’d never find anything. Adding folders helps you arrange and sort your groups. While folders add little value to your computer’s file-system, these category groups can actually be beneficial beyond just organizing. For instance, if you add these category groups to your serving teams, the categories can act as leadership teams for their sub-groups. Take a look at this example of the first impressions serving teams at a large multi-campus church:

Notice how each campus and ministry area has a leadership group. These groups not only help arrange the serving teams, but they can also have members of their own that represent the leadership team for each area.

Types of Group Schedules

There are three types of group schedules that can be configured for a group. To help simplify the editing of a group we allow you to configure which of these options are available to groups of each particular type. For instance, you'll probably want to configure your Small Groups to only be configured to allow the Weekly schedule. You can select which of these options are available for a specific group type under Admin Tools > General Settings > Group Types

Schedule Exclusions

Picture this: you've just finished entering all of your small groups into the system with their correct schedules and your supervisor just announced that, "groups are taking a two-week break." Not a problem! Adding a Schedule Exclusion to the Small Group group type will add the exclusion(s) to the schedule of all groups of this type. This is done under Admin Tools > General Settings > Group Types. This not only keeps the schedule accurate it also keeps attendance reminders from being sent while groups are not meeting.

Configuring a Group for Attendance

Before a group can take attendance, its group type must first be configured to enable attendance tracking under Admin Tools > General Settings > Group Types. From here you should select the group type you'd like to configure check-in for. Under the General tab enable setting Takes Attendance.

While this one setting is all you need to enable the attendance features, there are a couple of other settings that help improve the attendance tools:

• Group Schedule Options: While a group schedule is not required to take attendance, having a schedule will simplify the attendance entry because it will guide the user to enter attendance on those dates when the group meets.
• Schedule Exclusions: While each group can set its own schedule (including exclusion dates) you may want to set exclusion dates for every group of this type. This is especially helpful when using the simple schedule option where you only specify the day of the week and start time for a group. Adding these group type schedule exclusions help to keep email attendance reminders from being sent.
• Send Attendance Reminder: This checkbox will enable the sending of an attendance reminder email to the group leader the day the group is scheduled to meet.

Entering Attendance Information

Internal Attendance Features

There are several ways to collect group attendance. The first is to use the internal attendance features built into the group viewer under People > Group Viewer. You'll notice an attendance button on the group details block for groups that are configured to take attendance.

Selecting this option will bring up the group attendance grid. This grid lists the previously entered attendance for the group and allows you to enter new attendance records from the add button in the grid's footer.

Selecting the button will take you to the attendance entry screen below. From this screen you can check off all those who attended the group or note that the group did not meet on its scheduled time. You can also print an attendance sheet which allow attendance to be collected via a register.

Rapid Attendance Entry

The Rapid Attendance Entry method of recording attendance may come in handy for your groups. To learn more, see the Rapid Attendance Entry chapter of the Checking Out Check-In manual.

Attendance Reminders

As noted in the configuration section above, you can also configure Rock to send an email to the group leader on the day that their group meets to remind them to take attendance. This email will include a link to take them straight to the attendance detail screen. Since each group leader gets an individual email, we have enabled this link to not require a login to help simplify the process (the user however must have edit rights to the group to enter attendance).

There are two other configuration points for attendance reminders. The first is the system email that is used as the template for the email. This template can be edited under Admin Tools > Communications > System Emails > Group Attendance Reminder.

The other configuration point is the job that is run to send the emails on a daily basis. This job must be created for every group type that requires reminders. For more information on this job see the Service Jobs Relating To Groups section below.

How To Follow

Following is super simple. First navigate to the group you'd like to follow. Then, press the follow star in the upper right of the group detail block.

Following a group also enables several other features. For instance, when you have an event registration that places registrants into a group, you can configure the registration to also notify all individuals who are following that group.

Group Member Roles

People often have special roles in groups. Some are leaders; others have unique duties. To help differentiate the members of a group, you can give each a Group Member Role. The list of possible roles are defined on the group type. Each role has the following configuration options:

• Is Leader: Determines if the individuals in this role are considered leaders within the group. This option enables additional functionality within Rock.
• Can View: This gives the members of this role the ability to view the group information in various group toolbox blocks.
• Can Edit: Allows members to edit group information in various group toolbox blocks.
• Minimum Required: Rock allows you to have rules on how many individuals can have certain roles. This setting configures the minimum number of individuals who must have this role. This will keep you from deleting a group member if the deletion will drop the number of individuals with this role below the minimum.
• Maximum Allowed: This setting is like the minimum but limits the number of people who are allowed this role. For instance, you might configure a group type to only allow one person to be the leader. You can also use this option to limit the number of adults in a family. A family is a group type.
• Default: When someone is added to a group, this will be the default role they'll be assigned to. Note: Some blocks will have a block setting that overrides this default. This setting will handle cases when a block does not provide an overriding setting.

Group Member Status

The status of the group member tells you the person's standing within the group. The available statuses are:

• Active: The individual is currently participating in the group.
• Inactive: The individual is not currently participating in the group. Usually this status denotes that the person did participate at one point but isn't doing so anymore. How you choose to use this is up to you.
• Pending: The individual has not yet fully joined the group.

Group Member Attributes

Group members can also have attributes. This allows you to track custom data points for each person as it relates to their membership in the group. Usually these Group Member Attributes are defined on the Group Type under Admin Tools > General Settings > Group Types. When they're configured here, the attributes will apply to every group member of this type. You can also add Group Member Attributes to a specific group under People > Group Viewer > Group if you have Administrate access to the group.

Editing a Group Member

Selecting a group member from a group member list will take you to the group member detail screen show below. From here you can change the role and status of the group member. You will also be able to modify any of the Group Member Attributes defined for the group. You will also see a note field for the group member. This is useful for keeping basic notes. Rock uses this field to provide specific information about the group member when processing things like workflows and alternate placements.

If a group member has a note attached, a small note icon will display on the group member list to help identify this face.

It is also possible to move a group member from one group to another. When you do you will be given the option to transfer any group member notes to the new group.

Group Member Workflows

By now you realize that groups are the backbone of Rock. So it makes sense that we'd invest in making them as powerful as possible. Group Member Workflows are one of these investments. So what do they do?

Group Member Workflows are an easy way to trigger workflows to launch when the state of a group member changes for a specific group. These events include:

• Being added to a group
• Being removed from a group
• Member status changes (e.g. status changed from Pending to Active)
• Member role changes (e.g. role changed from Attendee to Leader)
• Member attendance
• Member alternate placements (discussed in detail in the next chapter)

The workflows you define for these triggers can be configured for all groups of a specific type under Admin Tools > General Settings > Group Types or for a specific group under People > Group View > Group. Below is the screen you'll see in either case.

1 Name

This is the name you want to use to describe the trigger.

2 Active

Indicates whether this trigger is currently active.

3 Start Workflow

The workflow type you'd like to start when the trigger conditions are met.

4 When

This determines when the trigger should be considered.

5 With Status Of

This allows you to filter when the trigger is applied for members with a specific status.

6 With Role Of

This allows you to filter when the trigger is applied for members with a specific status.

7 From Status/Role Of

Determines what the original status/role was to use as a trigger filter.

8 To Status/Role Of

Determines what the new status/role must be for the trigger to fire.

9 First-Time

Determines if this trigger should only be activated the first time a person attends this group or everytime.

Tips For Creating Triggered Workflows

When workflows are started from the group member triggers, they will pass in a few attributes for your convenience (as long as the attributes are definded). These include:

• Person: The person that the group member represents.
• Group: The group that the person is a member of.
• AttendanceDateTime: Only applies to the Member Attended Group trigger type and is the date/time that person attended the group.

Whenever possible, the workflow will also pass in the Group Member model as the entity of the workflow. You can access the group member properties and attributes by using the Attribute Set From Entity action with the following lava:

In some group usage scenarios you may want group leaders to be able to remove someone from their group but not have the group member fall to the wayside. Alternate placements allows you to do just that.

The first step is to configure the group type to have an alternate placement group member workflow. We discussed creating these workflows in the previous chapter. This member workflow type has two options: Show Note and Note Required. This allows the group leader to notate the reason why they are seeking to place the group member elsewhere.

The Group Member Detail screen contains a button that allows you to initiate an alternate placement workflow. When you click this button, Rock displays the Move Group Member window, where you can select which configured workflow to launch (if there is more than one) and allow the leader to enter a note (if it's configured to do that).

When the Move button is click, the workflow is launched and the person is removed from the group.

Enable Group History

To enable Group History for all groups of a certain group type, begin by locating the group type in Admin Tools > General Settings > Group Types. In the General section of the Group Type Details screen, check the Enable Group History checkbox. You can customize the group type's display options in the Display Options section by assigning it a color and icon. These options come into play in a number of the Group History views, but we'll get into that later. For now, click Save and Rock will enable the history and options for that group.

View Group History

Now that you have Group History enabled, you can jump to that 40,000ft view. Locate the group in the Group Viewer and click the button.

This brings up the group's timeline view, shown earlier, including both member and group history information. The Group History screen shows the history of the group by day for the lifetime of that group. Each event on the timeline has an icon that corresponds to a type of action.

• - Member added
• - Member removed
• - Group edited
• - Other/general group action

If there is more information than space available for an event on the timeline, you can view the entire contents by hovering your mouse over the text. For multiple occurrences on the same day, Rock will display link to expand the area to display all of the actions for that day.

To hide member history and view only actions made on the group level, click the button.

You can also zoom in from that 40,000ft view and get a closer look at the history of the members of a group. Click Member History to display a group's members and the history/dates of their involvement in the group. Click on a specific person to view a timeline of their involvement with the group.

View Group History in a Person's Profile Page

Individual group history is also available on the Person Profile, under the Groups tab.

Hover your mouse over any of the events on the person's timeline to display the details of that event. Note the timeline colors correspond to the color assigned to the group back when Group History was enabled. If the person is a group leader, the color will be slightly darker. You can also click on a specific event to drill down into the group. As with all of the tabs on the Person Profile, the information is filterable. Click the button to display the filter options.

Group List Personalized Lava

This block shows a listing of groups that the current user is a member of. Through block settings you can configure which group types to show or not show. Using Lava you can adjust the look of this block to your heart's content.

Group Detail Lava

This is the money block. With this block, you have access to every detail of a group that's accessible in a Lava template. It also has some special Postback Commands that allow you to enable editing of the group details and its members. The sky is really the limit when it comes to customizing the look of this block.

Group Attendance List and Detail

These two blocks allow you to track the attendance of a group. By default these options will only show for groups of a type with attendance enabled.

Group Registration

Registering for a group is a simple process using Rock's Group Registration block. Out-of-the-box this block will ask for basic contact information for the individual and their spouse. By adjusting the block settings you can customize this block in several different ways. Let's walk through each one:

• Mode: There are three entry modes for the registration form.
  • Simple: This mode only asks for the individual's first name, last name and email address.
  • Full: This mode additionally asks for more contact information including home phone, cell phone and address.
  • Full With Spouse: This mode is identical to the normal Full mode but adds the spouse's first name, last name, cell phone and email.
• Group Member Status: This setting determines the group member status that will be used when they are added to the group. Options include Pending, Active or Inactive.
• Connection Status: The registration form will attempt to find a matching record in the database using the first name, last name and email. If a record cannot be found, a new record will be created in the database. When that occurs, this will be the connection status that is used for these new records.
• Record Status: This represents the record status that will be used for new records. It's best to leave this as Pending so individuals on your data integrity team can manually review them for possible duplicates and merge the records if needed.
• Workflow: This option allows you to launch a workflow after the registration. The group member will be attached to the workflow as the Entity.
• Lava Template: This is a Lava template that will be applied to the top of the registration block. This allows you to customize the experience for the individual.
• Result Lava Template: This Lava template is used to craft a response message after the registration is completed.
• Result Page: You can optionally send the individual to a new page after the registration is processed.

Group List

Like its name suggests, Group List block lists all groups that match a specific filter. The power of this block lies within its block settings. They allow you to:

• Include Groups Of Type: Specify which group types to include in the list.
• Exclude Groups Of Type: Specify which group types not to show in the list.
• Detail Page: The page you would like to navigate to when someone selects a group from the list.
• Limit to Security Groups: Remember that security groups are a bit special. While there is a group type for security groups, any specific group can be configured to act as a security group. This setting shows groups that meet any of these criteria.
• Display Filter: Determines if the filter panel should be displayed above the list.
• Display XYZ Column: This block also has several block settings to hide or display columns for displaying group type, group description, active status, group member count and system status.

Below is an image of a sample group list.

Group Tree View

The Group Tree View block is very similar in configuration to the Group List block except that it displays the groups in a hierarchical tree view. Below is a sample of what this block would look like.

Group Details / Group Member List / Group Member Details

While these are three different blocks they are usually used together to fully display the contents of a group with the ability to edit.

Group Type Map

The Group Type Map block maps the location of every group of a specfied type. While not included on a page out of the box, this is a very powerful block for mapping all of your small groups. Small organizations could even use it to map all the families in the database (remember families are groups too). Below is a sample of this block in action.

Group Member Add From URL

Say what? OK, this is easy... this block when passed a PersonGuid and GroupId through the query string will add the person to the group and display a Lava template of your design. This is very useful in crafting various group registration scenarios. To get the juices flowing think about all the things you could do with this using the Dynamic Data and Group Finder blocks. There you go!

Group Member Remove From URL

This block is just like the Group Member Add From URL block - but the opposite. It takes a PersonGuid and GroupId through the query string and will remove the person from the group and display a Lava template of your design. This allows you even more flexibility in creating group registration situations. Alright!

Group Simple Register

This block is another block that's handy for registration scenarios. It provides a simple form that accepts a first name, last name, and email address, registers the person to a group, and then forwards them on to a confirmation page. This block is most useful when it's used on an external facing site as a simple first point of contact but is flexible enough for many other scenarios!

Simple Register Confirmation

This block is designed to pair with the Simple Register block as a confirmation page. When a user is redirected to this page it provides either a success or a failure message. It's that simple!

Group Registration

This block is the big brother of the Simple Register block. This block takes a GroupId as a query parameter for context and allows you to do a few neat things like fire off a workflow when a user registers and use Lava options to format the registration form. It also has a full mode that takes down address details and phone details and a full with spouse -- which does exactly what you might expect. Use this mighty block when you want to get more than your standard information about a person or when you want to use a specific workflow process for your registrants.

Group Map

The Group Map block maps the members of a specific group that is passed through the query string (aka passed in through the address of the page http://server.com/page?GroupId=12). While this block isn't too powerful on its own, it can be very helpful when used in conjunction with other blocks like the Dynamic Data block. Below is a sample of what this block looks like with with a sample group.

You'll notice two sets of checkboxes on this block. These allow you to map various groups and families that live in these areas. Below is a description of how and when these checkboxes will appear.

Group / Group Member Checkboxes (top left)

• If the selected group has a valid geopoint, or geofence location, that group's name will be displayed as a checkbox option in the upper left which can be used to toggle the display of the group. The group will be displayed on the map either as a marker or a polygon depending on whether the selected group had a geopoint or geofence. The color of the marker or polygon is determined by the first color specified in the Colors attribute of the selected mapstyle defined value. Note: this option will not appear if the selected group does not have a geopoint or geofence defined.
• A Groups checkbox will be displayed if the selected group has any child groups with a valid geopoint or geofence location. The child groups may also be either a marker or a polygon. The color of markers is determined by the second color specified in the Colors attribute of the selected mapstyle defined value. The color of polygons is determined by the Polygon Colors block setting.
• A Group Members checkbox will be displayed if the selected group has any members with a valid geopoint location. The checkbox will toggle the display on the map of those members. Note, if the selected group is displayed as a polygon, these members may or may not be within the boundaries of the polygon. The color of the markers is determined by the third color specified in the Colors attribute of the selected mapstyle defined value.

Connection Status Checkboxes (top right)

• If the selected group has a geofence location and is displayed as a polygon on the map, then the block will also display a list of Connection status checkboxes to toggle the display of families whose locations fall within the boundaries of that polygon.
• The connection statuses that will be included as checkbox options are determined by the Connection Status Defined Values. Only those defined values that have a value specified in the Color attribute will be displayed. The color value is also used to determine the color of the markers.
• Only families with at least one active record will be included.
• If family members have different connection statuses, they will be ordered by the connection status defined value order, and the first connection status found will be used for the family. For example, if a family has a member and a visitor, the family will be displayed when the Member checkbox is selected.

Send Attendance Reminders

This job sends reminders to group leaders to enter attendance. All individuals in the group with a role that has the 'Is Leader' setting will receive this reminder. 'A couple of key configuration options for this job are:

• Group Type: The group type that the reminders are for.
• System Email: The system email that you would like to use for sending the reminder.
• Send Reminders: By default, a reminder will always be sent the day the group meets. By adding values here you can configure additional reminders if the attendance has not been entered. For instance, entering 2,4 would send reminders 2 and 4 days after the group has met if no attendance has been entered.

Group Leader Pending Notifications

This job allows you to notify group leaders of newly pending members in their groups. This provides the following customization options:

• Group Type: The group type to filter off for limiting the groups that are checked for pending members.
• Include Previously Notified: This determines if only newly pending members should be emailed to leaders or if pending members who have already been sent once should also be considered. Note that when you initially set up this job, none of the current pending members will have been marked as sent, so they will all be emailed to leaders on the first run.
• Notification Email: This is the system email template that should be used. A sample one is provided out of the box for you to use or edit as you see fit.
• Group Role Filter: This is an optional setting that allows you to only include pending members of a specified role. If you don’t select a role, all roles will be considered.

The email notification will be sent to all group members of the group whose role has been configured as Is Leader.

Defining Group Requirements

You manage group requirements under Admin Tools > General Settings > Group Requirements.

Editing a requirement allows you to provide the following configuration options.

Editing Group Requirements

1 Name

This is the name of the requirement.

2 Description

Be sure to provide a good description of the requirements and any of the underlying criteria that are used to determine whether a group member meets the requirement. A little documentation now will save you headaches in the future.

3 Positive Label

This is the label text that will be show when a group member meets the requirement.

4 Negative Label

The label used when a group member does not meet the requirement.

5 Warning Label

The label text that should be shown when the check meets the warning condition.

6 Can Expire

Some requirements, once met, will always be true - say for instance a requirement that you take a specific class before serving. Other requirements may expire. A good example of this is a background check or CPR certification.

7 Expire in Days

When a requirement can expire, you can set the number of days in the future to wait before re-checking the requirement. For something like a background check you don't need to look every day to see if the background check is still valid.

8 Check Type

So how do we determine the logic of whether someone meets a requirement? Rock gives you three options:

• SQL: In this case you provide a SQL statement. This statement should return a list of Person Ids in the database that meet that requirement.
• Dataview: You can also select a dataview that returns a list of all the people who meet the requirement.
• Manual: This requires someone to manually determines if a person meets the requirement.

You'll notice that the SQL and Dataview options give you a separate property to determine the warning state. You can leave this blank if your requirement doesn't have a warning state.

Applying Group Requirements to Individual Groups

Once you have defined your requirement, you can apply it to groups. If you have Administrate access to a group you'll notice a panel on the edit screen entitled Group Requirements. You can add group requirements from this panel. There is also a setting to keep group members who don't already meet the requirements from being added to a group.

Applying Group Requirements to Group Types

You can also set group member requirements at the Group Type level. This allows you to apply member requirements to all groups of a certain type rather than to each individual group.

To access your group types, go to Admin Tools > General Settings > Group Types. Select the group you want to add requirements to from the Group Type list. In the Group Type Detail screen, expand the Group Requirements section. From here you can either select an existing group requirement to edit or click the button to add a new requirement.

Viewing Group Requirements

Once you enable group requirements you'll notice in the Group Viewer that certain group members may have warning icons next to their names. This yellow icon denotes that the group member either does not meet the requirements or is in a warning state.

Group Requirement Jobs

The Group Requirements features rely on two system jobs. These jobs can be configured under Admin Tools > System Settings > Service Jobs.

Fundraising Walk Through

Keep in mind that each fundraising opportunity is a group. You'll manage the opportunities from the Group Viewer.

Ok, but that's the boring part. Let's start looking at how these groups are displayed on your external site! Out of the box Rock configures several pages to view fundraising opportunties. The pages are display under the Missions pages (found under the Connect menu item). The missions page lists the various opportunites that are marked Show Public. Keep in mind that this block can be filtered by Opportunity Type.

Selecting one of the opportunities will take you to its detail page. In the example below, Ted (who is leading this particular mission trip) is viewing the page. Since we know it's Ted, a summary of his Fundraising Progress is shown. Links are also displayed to take him to his participant's page and for him to make a payment. Also, note that since Ted is a leader for this opportunity, he has access to a leader toolbox.

This page is also used for the general public to view. It allows them to easily register for the opportunity if a registration instance was provided.

Fundraising Opportunites can also optionally be configured with a Content Channel for providing updates. When configured, a new tab will be shown to display these updates.

Another optional setting is to allow commenting on the opportunity. This tab will display a Rock notes control. Keep in mind that this feature currently doesn't allow for approving comments and does not email when new comments are added.

Each opportunity participant has a personalized page that they can share with others to help generate interest and help encourage funding.

Each participant can provide a custom opportunity introduction and edit their profile image from their personalized page. This block can also be configured to edit specific person attributes if you wish.

If the person logged in is the participant, they can also view the gifts that have been given.

If someone doesn't have a link to a participant's profile page they can choose to give from the opportunity detail page and select the participant they would like to fund.

Fundraising Opportunity Configuration

As we mentioned earlier, Rock's fundraising features are driven by a set of group and group member attributes. Let's take a look at these settings to see how you can customize each fundraising opportunity to meet your individualized needs.

Keep in mind the group and group member attributes below are specific to a single fundraising opportunity (each one is a group). This allows you to have several types of opportunities, each with their own unique settings and configuration.

Group Attributes

Below is a detailed discussion of each setting for the group that represents the opportunity (Mission Trip, Internship Season, etc.)

Name	Type	Description
Opportunity Title	Text	The group name is mainly used internally. This attribute of Opportunity Title is what will show on the external site when opportunities are listed.
Opportunity Date Range	Date Range	Used to show the start and end dates of the opportunity. For a mission trip, we would recommend that you put the trip dates here. This date range doesn't control when the opportunity is shown externally; it just describes when the opportunity occurs.
Opportunity Location	Text	This is the location of the opportunity. For a mission trip, this would be the city or country. Feel free to leave this blank if it doesn't make sense in your situation.
Opportunity Summary	Memo	A brief description of the fundraising opportunity.
Opportunity Photo	Image	If a picture is worth a thousand words, then we'd better include one.
Opportunity Details	HTML	Now we get to the nitty-gritty of what this opportunity is all about.
Individual Fundraising Goal	Currency	This field determines how much money each person is trying to raise. If each person in the opportunity is raising different amounts, you can provide those unique amounts on their group member attribute (discussed below).
Opportunity Type	Defined Value	The opportunity type helps group-like opportunities. Rock ships with three options (Trip, Internship and Project). You can add your own under General Settings > Defined Types > Fundraising Opportunity Type. This setting has two roles: Acts as a filter for opportunities on the external website (e.g. show only mission trips on this list) Provides a label to describe the opportunity type. For instance, should this opportunity be referred to as a Trip, Project, etc.
Update Content Channel	Content Channel	You may want to provide updates on the status of your opportunity. For example, if your opportunity is a mission trip, you might want to file trip reports. Or if it's a project, you might want to provide updates on the overall funding level or project status. This setting allows you to configure a content channel to manage these updates. If you don't provide a channel the updates tab will be hidden.
Enable Commenting	Boolean	Sometimes you want comments, sometimes you don't. When enabled, a notes block will be added to the opportunity detail. Just remember that there is no automatic email when new notes/comments are left and no approval process. These features may be added in a future release.
Registration Instance	Number	This is what ties in a registration to the fundraising opportunity. You must provide the registration instance ID (currently there isn't a registration instance picker).
Registration Notes	Memo	This short description will show up on the opportunity details page to provide any quick notes about the registration (e.g. A $200 deposit is required).
Allow Individual Disabling of Contribution Requests	Boolean	Opportunity participants can have their own personalized fundraising pages. Some participants may want to use this page to share the opportunity and provide updates, but not want to communicate the financial needs. This setting allows you the option to allow them to disable the sharing of their funding status.
Allow Individual Editing of Fundraising Goal	Boolean	This allows individuals to set their own fundraising goals from their external fundraising profiles. The default for this is not to allow editing.
Cap Fundraising Amount	Boolean	This setting determines if an individual can raise more money that their goal.
Financial Account	Financial Account	This configures which financial account the fundraising opportunity should use to track their money.
Show Public	Boolean	This flag determines whether the opportunity should be displayed on the external website. Since it's common for an opportunity to be displayed long before it starts, and for a brief time after it ends, this flag is used to determine when an opportunity should be displayed.

Since many of these attributes drive the external display of the opportunity, let's look at an example and where each value this shown.

1 Opportunity Title

2 Photo

3 Date Range

4 Location

5 Summary

6 Details

7 Trip Updates

8 Comments

9 Registration Status

This is determined by looking at the dates on the registration instance. If the registration is not yet open, the future opening date will be displayed.

10 Registration Contact

The contact comes from the Registration if it is configured.

11 Registration Note

12 Spots Available

This is calculated by looking at the number of registrant openings available for the registration.

Fundraising Financial Transactions

Financial Transactions that are created from the fundraising features will all default to the Contribution type. The account for the transaction will be applied based on the opportunity group setting. It is possible to change the transaction type to a different value than Contribution. To do so, you'd need to create a new page with a Transaction Entry block on it. This block has a block attribute to set the transaction type on the advanced setting panel. You'd then need to configure your fundraising pages to use this new page for processing financial transactions.

In Rock, financial transactions can be tied to another entity (event registration, etc.). Donations that are made as a part of fundraising will be tied to the Group Member of the Fundraising Opportunity group. The is no financial linkage to registrations. This is an important point to understand as there is no way to link money coming in to a registration with that given as a fundraising opportunity. Below we cover several ways you can configure event registration to work with the fundraising tools for maximum impact.

Financial Transactions Matching

We've already discussed that Financial Transactions for fundraising are Contributions that are tied to the Group Members of the Fundraising Opportunity Group. The Rock tools mentioned above do all of the connecting of the group member to the transactions. You might asking, "What about checks or gifts that need to be entered manually?" And that... is a GREAT question!

After entering contributions (either scanning and matching or through another process), you can link a contribution to a fundraising opportunity participant using the Fund Raising Matching block found under Finance > Fundraising Matching

Fundraising Progress

You can quickly track the progress of fundraising campaigns for fundraising groups. Start by going to the Group Viewer page (People > Group Viewer). From this screen you can view the individual fundraising donations for each group member.

You can also quickly view the group's overall fundraising progress. Click the button to display a snapshot of both the combined and individual fundraising progress.

How Registration Can Work with Fundraising

As mentioned above, Rock's registration and fundraising tools were meant to work together. That said, financial transactions from these two features don't tie directly together. Below are some use cases to show how you can get these two features to sing in perfect harmony.