State

The state of a request describes the standing of the request. There are only four options for state:

• Active: The request is currently being worked.
• Inactive: The request has either been completed or canceled.
• Future Follow-up: Often requestors will need more time before they are ready to be fully connected. The future follow-up state allows us to freeze the request until a specific date. This is helpful as it allows the connector to remove it from view until the specified follow-up date. The state will be changed back to Active by the Connection Request Workflow Triggers job based on the follow-up date.
• Connected: The request has completed the full connection process.

Status

You can define as many different statuses as you'd like for a request. These statuses are defined for each connection type. The statuses that have been configured for the Involvement connection type include:

• No Contact: This is the initial status of a request. It basically means nothing has been done with the request.
• In Progress: Once a connector has been assigned and communication has been attempted, then the status should be changed to In Progress.

Remember you can customize these statuses and add your own. For instance, you could have a status for In Training or Complete.

Activities

Activities are a listing of events that have occurred during the process of connecting the requestor. You can customize what these activities are. The involvement connection type is pre-configured with the following activities:

• Called: A phone call was made and the requestor answered.
• Called Left Message: Pretty much says it all.
• Called No Answer: You can probably figure this one out too.
• Contacted Waiting for Response: Some type of contact was made and the request is waiting for a reply.

While each request will only have one value for state and status, they can have as many activities as needed.

Now that we understand the properties of requests, let's see them in action.

1New Connection

Sara Simmons makes a request from the website to get connected into the ushers opportunity. From this, a new connection request is created with the State of Active and the Status of No Contact. Also note that at this point no Connector is assigned.

2In Progress

After seeing it, Alisha Marble assigns herself to the new request and makes a first attempt at contact with the requestor. Unfortunately, Sara was at her daily spin class and missed the call. At this point, Alisha changes the status of the request to In Progress and adds an activity of Called No Answer.

3Future Follow-up

In a few days, Alisha tries calling again and this time is able to reach Sara. After talking, Sara decides that it might be best to wait four weeks until things settle down at the hospital where she works. Alisha now changes the state to Future Follow-up with a follow-up date of 9/15. At this point the request will be hidden from her list of requests until 9/15.

4Connected

On 9/15 the request pops back up on Alisha’s radar and she makes another call to Sara. During this call they conclude that Ushering at the noon services makes the most sense for Sara's schedule. Alisha then connects her to the group and marks the request Connected.

5Picks Group

As a part of the Connected step, Alisha picks the group to connect Sara to. While the connection process doesn't have to always end with placing someone in a group, it will in most cases.

6Workflow

We promised you workflows and here's a taste of them. Workflows can be set up to automatically launch when certain conditions of the request are met. In this case a workflow was defined to launch whenever someone was Connected that sends out some training materials. We'll look more at workflows soon.

The Role of Campus

Campus plays an important role in the connection process, particularly for multi-campus sites. As requests come in, they will be attached to a campus. Also, the connectors and assigned connection groups can be partitioned by campus. We'll see how to set this up later. For now, just know that the connection opportunities can be shared for all campuses while still providing support for campus-specific requests.

Spotting Connections a Mile Away

Connection requests are shown prominently on the person profile page to help give you an overview of a person's connection at a glance. Each connection request listed on the profile page lists the connection type, opportunity, campus and status.

List View

As we mentioned above, you can click the icon in the top-right of the block to toggle between the List and Board views. Since we’ve already seen the board view, let’s shift over to the list view. You can see that both views are similar, but we’ll highlight some key differences you’ll want to know about.

1 Grid Options

The first thing you might notice about the list view is that the connection requests are in a grid. This opens the doors to all kinds of actions you can take for the people in the list, from sending communications to launching workflows.

2 List View Columns

The list view shows a lot of the same information as the board view, but with some additional details. For instance, you can see both the State and Status, as well as the last Activity that was performed.

3 Action Icons

With a single click you can go directly to the Person Profile page for the person by clicking the icon. You can also delete the request by clicking X.

If you have request security enabled you'll also see the icon which you can use to update security for the individual request.

4 Rows Per Page

The list view is best when it comes to handling large volumes of requests. Controls like these are already in place to help you navigate very long lists. Viewing hundreds or perhaps thousands of requests in the board view, while possible, might result in performance issues that can be avoided by sticking with the list view.

Connection Request Detail

We've seen connection requests at a high level, but now it's time to get into the weeds. Accessing any request from either the List or Board views will show its details as pictured below.

1 Request Labels

At the top of the details screen pictured above you'll see several labels. These include (in order):

• Campus (if applicable)
• Connection Opportunity
• State
• Status

2 Requestor

This is the person that is in the process of being connected. You can update the block settings to provide custom Lava that will render above the person's name.

3 Contact Information

The contact information for the requestor is shown to help speed up the process of contacting the individual. You'll also note that there's a quick link to the right that will take you to the requestor's Person Profile.

4 Connector

The currently assigned connector is displayed for reference, but you can quickly change the connector (or assign one if nobody is assigned yet) by clicking in this area.

5 Placement Group

This is the group that the person will be added to when the request is connected. The groups that display in this list are configured on the Connection Opportunity Detail screen. You'll learn more about these settings in the Configuring Connection Types chapter. For now, just know that you can limit the groups displayed here. Also note that this list of groups will be filtered by the campus of the request.

6 Lava Badge Bar

If configured in the block's settings, a custom badge bar for the connection request will be displayed here.

7 Connection Request Attributes

Connection request attributes can be displayed here, and will be grouped under tabs according to their category. If some attributes have categories and some don’t (as pictured in the example screenshot above) an "Attributes" tab will be added for those without a category. In this case, we have attributes assigned to the categories of Orientation and Training, so we see those tabs. We also have one attribute called “Planned Start Date” that isn’t assigned to any category, so it falls under the Attributes tab. If none of the attributes have categories then you won't see any tabs.

8 Available Workflows

Many of the workflows will be automatically triggered by events to the request (like changing statuses). You can also define manual workflows that can be launched by the connection team at any time. When defined, these workflows will be displayed here.

9 Edit

This allows you to edit the details of the request, including the Connector, State, Status and Assigned Group.

10 Transfer

This allows you to transfer the request to another Connection Opportunity. We'll talk more about transferring later.

11 View History

Click the View History link to open a new page that lists updates and changes to the request. You can see things like when the request was created, status and state changes or when the person was connected.

12 Connect

Select this button to complete the connection process. This will drop the person into the group and mark the state as Connected. This button can be hidden by changing the opportunity's configuration as described in the Configuring Connection Types chapter.

13 Activities

This is a list of activities for the request. You may notice that some requests' activities are highlighted in blue while other activities are white. The activities with a blue background color represent those that are for this specific request. Activities without the blue highlights are activities that are from other requests in the same connection type. You can only remove the activities you've added, otherwise the "X" will be greyed out.

14 Workflows

You can expand this area to show any workflows that have been initiated for this request, as well as the status (e.g. Running, Complete) of those workflows. Both manual and triggered workflows will appear in the list.

You might be wondering why you'd ever want to see activities from other opportunities. It's not uncommon for overly-ambitious requestors to sign up for multiple connection opportunities at once. Viewing activities from one opportunity in other opportunities allows you to see that they are being contacted by more than one connector.

This functionality can be disabled if needed. More on that later.

Adding Activities

You can add new activities by selecting the button. This brings up the Add Activity window.

You can use entity attributes to enter additional details related to the activity. Those attributes will be added to the window above according to your setup.

Transferring a Request

During the connection process it's common that the requestor (or connector) decided that this opportunity isn't a great fit. The transfer feature is a quick and powerful way to ensure the requestor can find a new opportunity that works for them.

Click the Transfer button to bring up the transfer screen below. While it looks pretty simple, it has some powerful capabilities.

1 Opportunity

This is where you can select a different opportunity for the individual, if needed. By default the opportunity being viewed is selected.

2 Search

This allows you to find the best next opportunity. We'll dive deeper into this next.

3 Status

This allows you to select the new status when the request is dropped into the new opportunity. This can be shown or hidden based on the opportunity's configuration.

4 Connector

Most of the time you'll want to clear the current connector when you transfer the request. Sometimes you'll just want to select a new connector without changing the opportunity. Either way, the options provided here allow you to select:

• The default connector for the opportunity
• The current connector (whose name, if available, will be displayed here)
• A new connector (which you can choose from the dropdown that displays when the option is selected)
• No connector

5 Campus

If enabled in the opportunity's configuration, and if you have more than one campus, you can transfer the request to a different campus using this drop-down.

6 Note

This allows you to send a note to the new connection team.

Through the transfer process you want to make sure you find each individual the right next opportunity. Otherwise they might feel like a hot potato. The Search button allows you to look at all the new opportunities to help coach them on what might be best for their personality and situation. Below is the search screen for the Involvement connection type.

Displaying Badges

Badges are a great way to see a lot of information about a person at a glance. Displaying badges on your connection requests can save staff from having to look elsewhere for the information they need to get the right people connected to the right opportunities.

In the example pictured above we’re displaying the Connection Status, Baptism and Serving Team badges. You can choose which badges to display by editing the Connection Request Board block settings as shown below.

Select which badges you want to display and click the Save button. Those badges will now be displayed for anyone with those connections. Super easy!

Also within the block settings you can use the Lava Heading Template and Lava Badge Bar to further customize the page. The Lava Heading Template will appear above the person's name, while the Lava Badge Bar will appear below the person's details and above the attributes section.

Self-Service

Rock ships with blocks that allow you to create a self-service entry to the connection process. This has been pre-configured on the external website for the involvement connection type under Connect > Serve.

Here you will see the search page for finding involvement opportunities. It allows you to filter by campus and also by various attributes about the opportunity (we'll show you how to configure these below). Selecting an opportunity will display its details.

From the details page, the guest can then choose to Connect with the opportunity. This action creates a connection request.

In the example pictured below, a custom attribute has been added to request "Begin Date" information from the individual.

Connection Request Attributes

To set up attributes for the connection request, go to Admin Tools > System Settings > Entity Attributes. Add an attribute with an Entity Type of "Connection Request". The attribute's configuration can be used by the signup block to control which attributes will appear. You have different options for controlling this.

You can select specific categories to include or exclude. To set up categories for this, navigate to General Settings > Attribute Categories and add a category with the Entity Type set to "Connection Request". That category can then be assigned to your connection request attributes, so they can be included or excluded in the signup block's settings.

You can also use the Public flag in the attribute's setup to control which attributes are shown. There's a simple setting on the signup block where you can blanketly exclude non-public connection request attributes. This can be used in place of, or in conjunction with, included or excluded categories.

Staff Entry

As discussed above the staff can also enter requests from the internal site under People > Connections.

Workflows

Rock also ships with a workflow action that can create a new request. This is a powerful way of creating your own request screens using the workflow entry actions. See the Connection Workflows chapter below for more information on how you can configure workflows to best use the connection features.

Configuration

Let's say for instance that we’d like our Children's connection opportunity to allow placement into three different serving teams. We'd also like the connector to be able to place them into the groups as either a Leader or a Member. Finally, if they are a Member of the group we'd like for the connector to be able to place them with the member status of Active or Pending. That's quite a list of requirements... let’s see how we can configure the Children's opportunity to do just that.

You can set up placement groups in the Connection Type configuration screen. Here you'll find a panel for setting placement group options. The screen below shows the configuration for the example given above.

1Placement Group Configuration

The first things we configure are the group types, roles and statuses that will be options for our placement groups.

2Group Member Role

Next, we configure the one option for the Leader role.

3Group Member Status

Note that we configured two different options for the role of Member for the group type of Serving Team. One option allows for the Group Member Status of Active the other for Pending.

4Placement Groups

With our roles and statuses configured we can now select the specific placement groups for the opportunity. In this example, you'll notice that we've selected three different serving teams.

In our example above we specifically picked each placement group that is an option for the connection opportunity. This will work in most cases. But if you wanted the list to show every group of a specific group type, you could configure that as well. This eliminates the need to configure new groups when they are added.

Results

With our configuration in place, let's see the fruits of our labor. The screen below shows the editing of a connection request for Helen Evans who is interested in helping in the Children's area. Let's walk through how the placement group settings drive the process of selecting a group.

1Placement Group

Once you select a placement group, options will appear below allowing you to select roles and statuses. The screen will only show these settings if more than one option exists. So, for instance since the role of Member is selected, the option of Group Member Status is displayed since we can choose to add them as Active or Pending. If on the other hand, we selected the role of Leader, the Group Member Status option would disappear since the only option is Active.

2Group Member Attributes

You'll also note that group member attributes are shown on this screen. In this case there's only one, the "Hours Serving" attribute. Showing the group member attributes here allows you to set these values quickly as you place the individual into the group.

Group Requirements

If a group has specific requirements to join, these will be checked before saving the placement group. If they do not meet the requirements, you will see a warning message like the one pictured below.

Building Connections Workflows

When the workflows above are executed, the initial activity of the workflow will have access to the connection request through the workflow entity property. It's important that this initial activity gets the information it needs to process from the request. The main action you'll use to get the properties from the request is Set Attribute From Entity. You can use the Lava Template field of this action to pull different properties of each request. Below are a few samples:

Get The Requestor – Attribute Type: Person
{{ Entity.PersonAlias.Guid }}

Get the Connector Person (if any) – Attribute Type: Person
{{ Entity.ConnectorPersonAlias.Guid }}

Get the Placement Group – Attribute Type: Group
{{ Entity.AssignedGroup.Guid }}

Opportunity Type – Attribute Type: Text
{{ Entity.ConnectionOpportunity.Name }}

Status – Attribute Type: Text
{{ Entity.ConnectionStatus.Name }}

State – Attribute Type: Text
{{ Entity.ConnectionState }}

Connection Workflow Actions

To facilitate even more power with connections we've added several workflow actions. They're outlined below.

Setting Up Connection Campaigns

Before diving into the details, let’s take a high-level tour of how a connection campaign works. The diagram pictured below shows the flow of a campaign.

1 Campaign Settings

We start by configuring our campaign. This includes defining:

1. The connection opportunity to link to
2. Who should be contacted by the campaign (think data view)
3. How to assign connectors
4. Whether people should be contacted on a continued basis

Obviously, there is a lot more detail to cover, but we’ll get to that in a minute.

2 Campaign Job

A job has been configured to process the setup above and create a list of people who should be added to the campaign.

3 Campaign List

This list can change over time (based on the dynamic filters of your data view and who has already been processed). While it’s not important to know where this list resides, it is stored as an EntitySet for those who are curious about the technical nature of the feature.

4 Connections

From the campaign list, connection requests are created.

Because the process ends with the creation of a connection request you may wonder, "Why not just create the connection request directly?" The answer is that we realize it may take days or weeks to process through the list. We don’t want the age of the connection requests to be skewed by the date the request was created, especially if it takes several days or weeks for a connector to be assigned. It might be perfectly reasonable for a request to be waiting for someone for several days. We want to be able to measure requests by age as a reflection of how efficiently connectors are working requests. This provides good accountability to the process.

Now that we’ve looked at the feature from a 30,000-foot view, let’s dive into each component in detail.

Connection Campaigns

We'll start with the Connection Campaigns page. This allows us to define as many campaigns as we’d like. You can find this list under People > Connections > Connections Configuration > Connection Campaigns.

As you can see, this lists the campaigns and provides a few metrics about each. These include:

• Active Requests: This is the number of active connection requests that are currently open.
• Pending Connections: This is the number of people still on the campaign list waiting to be moved to a connection request.

Selecting a campaign will take you to the Campaign Detail page.

Campaign Detail Page

This page is the control center for a campaign’s configuration. Below we'll walk through each section of the setup.

1 Campaign Name

The name of the campaign should make it easy to identify its purpose.

2 Active

Set whether the campaign is currently active or not.

3 Connection Opportunity

This is where you'll choose which connection opportunity the requests will be created in.

4 Requestor Data View

This is the data view that will be used to populate the campaign list.

5 Family Limits

It’s often the case that you’ll want to connect with just one person in the family. While you can attempt to configure your data view to handle this for you, we’ve made it easy to set this up. By checking “Limit to Head of Household” you can have your data view return as many people as you’d like, but only one connection per family will be made. The head of household will be used as the requestor for the entire family. This is also very helpful if your data view contains children, but you really want to reach out to the parents.

6 Opt Out Group

This setting will remove any group members of the selected group from the campaign list. While you could also add this to your data view, we’ve provided an easy out with this setting. Note that all families that the group member is a part of will be opted out of future connections.

7 Create Connection Requests

This setting helps determine when connection requests are created. You have the option of having them all created as soon as the job runs, or as they are needed. Selecting As Needed means requests will be created as there are people ready for them. Doing it this way allows for better accountability because the creation date tells you how long the request has been worked instead of how long it sat before someone did work it.

8 Daily Limit of Assigned Connection Requests

The number you provide here tells the Campaign Manager job the maximum number of connection requests that should be automatically created and assigned for each connector on a daily basis, provided there are any to create. This limit applies to everyone by default, but you can change the limit manually for individual connectors if needed. More on that in the What to Know About Connectors section. Keep in mind a value of 0 or blank will stop the job from creating and assigning any connection requests. In that case, all connection requests must be made manually on demand. Be careful when combining this with the "All At Once" setting, because you could create many requests that will never be assigned.

9 Number of Days Between Connection

This setting allows connection requests to be created on a routine basis for an individual (or family). Say you wanted to make a connection every 30 days with an individual. Set this value to "30" and thirty days after the original connection has been closed (status of Inactive or Connected) a new one will be created.

10 Prefer Previous Connector

This setting attempts to use the same connector for future requests. The key word here is ‘prefer’. If the original connector is not available or is over her daily limit, then the system will select a different connector.

11 Request Comments Lava Template (Advanced Settings)

This allows you to create customized "Comments" using a Lava template. The Person object and Family (group) object will be merged with this template prior to creating new connection requests. Example:

    Please contact {{ Person.NickName }} with a quick phone call.
    Here are the family members:
    {% for m in Family.Members %}
    * {{ m.Person.FullName }} - {{ m.GroupRole.Name }} 
    ({{ m.Person.ConnectionStatusValue.Value }}, {{ m.Person.RecordStatusValue.Value }})
    {% endfor %}
    

Easy Opt Outs

Consider adding a simple manual workflow on your connection request that will add the requestor to the opt out group. This allows the connector to simply click a button to keep the individual (and their family) from being contacted in the future if your campaign is set to reoccur.

Working with Connection Requests

There’s nothing special about working with the connection requests. A button at the top of the connections pages allows a person to create more requests from the campaign list for themselves.

Pressing this button will activate a modal to ask how many requests the individual would like to create.

What to Know About Connectors

Sample Recipes

Below are a few sample recipes to help you understand connection campaigns in more detail.

Steps

You can access your step programs under: People > Engagement > Steps. This is also where you’ll go to create new programs, which we’ll cover later in the Editing Step Programs section.

1 Name

The name of the step program.

2 Category

Categories are a great way to group and organize your programs. You can view and manage step program categories from Admin Tools > System Settings > Category Manager using the Step Program entity type.

3 Step Types

A count of all step types, either active or inactive, included in the program.

4 Steps Taken

A count of all completed steps for all individuals in the program.

Step Program

The Step Program page has a detail block at the top and a list block below. There’s actually a lot to see and do on this page, so for now we’ll just get familiar with the page itself before diving into the setup and maintenance in later sections.

Let’s take it from the top and look at the detail block first.

1 Program Name

The program name is displayed at the top of the page.

2 Description

A good description helps clarify the program’s purpose.

3 Category

The category assigned to the program is displayed for reference.

4 Step Program Metrics

These metrics provide good information on the overall program. The values include:

• Individuals Completing: This is a count of unique individuals who have completed the program. People who complete the program multiple times will only be counted once.
• Average Days to Complete: The average number of days to complete the program is calculated based on the earliest Start Date and the latest End Date across the steps in the program.
• Steps Started: A count of the number of steps that have been started, regardless of whether they were completed.
• Steps Completed: This is a count of all completed steps in the program.

5 Step Program Activity Chart

This is a stacked area chart (a chart where areas don’t overlap because they are cumulative at each point) showing completed steps by step type. This chart actually has a lot going on, so we'll wait to break it all down for you later in the Steps Charts section.

Next, let’s move down to the list block at the bottom of the page. Here you can see and maintain the step types included in your program.

1 Name

The step type names are each listed here.

2 Spans Time

You'll see a checkmark in this column if the step occurs over a period of time (as opposed to a step that occurs in a moment of time).

3 Allow Multiple

A checkmark will appear if the step type can be completed more than once by the same person.

4 Started

Shows a count of how many times the step type has been started.

5 Completed

Shows a count of how many times the step type has been completed.

6 Bulk Entry

The icon will take you to Bulk Entry page, where you can add steps of that type in bulk. We’ll cover how to do that below.

In the Editing Step Types section we’ll dive deeper into how the information in this block gets added and maintained.

Step Types

Next, let's shift our focus to one of the individual step types within our example program.

The layout of the Step Type page is very similar to the Step Program page. You’ll see a familiar detail block at the top, followed by a list of step participants below. From here you can maintain the list of participants and view their progress as they start and finish the step.

1 Name and Description

The name of the step type is shown at the top of the page for reference. A description for the step type adds context and meaning.

2 Step Type Metrics

These are the same metrics as discussed in the prior section, but showing only data for the individual step type being viewed.

3 Steps Activity Chart

This overlapping area chart shows when the step type has been started and/or completed. We’ll unpack all the pieces of this chart later, in the Steps Charts section.

4 Step Participants

All individuals who have started and/or completed the step type are listed here.

5 Date Started

This is when the individual started the step. This column only appears if the step type is configured to span time.

6 Date Completed

This is when the individual completed the step. If the step type doesn't span time, then this is the “Date” associated with the step (see Step Entry).

7 Status

The status for each person is displayed, using values configured at the program level (see Editing Step Programs).

8 Attribute

Any Attributes you create with the "Show in Grid" option selected will be displayed here. In this example we've added an attribute to show which pastor is related to the step.

In the Editing Step Types section we’ll dive deeper into how all of this gets set up and maintained. At this point it's just important to be familiar with the kinds of data shown on this page.

Step Entry

Shepherding individuals through your program can be done either from the Step Types page or from the Person Profile page (which we’ll examine in the next section). Whichever path you take, you’ll wind up at a Step Entry page like the one pictured below. This is where you'll maintain step type information for an individual.

1 Person

In this example we’re adding a step from within the Steps area, so we need to provide a person. Steps entered from the Person Profile page will automatically populate the person’s name.

2 Campus

If you have multiple campuses configured, you can optionally associate the step with a particular campus.

3 Start Date/End Date/Date

• Spans Time: If the step spans time then Start Date and End Date fields will be available. Use these fields to track the dates on which a person has started or finished a particular step. These are displayed as the “Date Started” and “Date Completed” fields on the Step Types page.
• Does Not Span Time: If the step doesn’t span time then you’ll see only a single Date field. In this case the date is treated as an end date, and will be displayed as the “Date Completed” on the Step Types page.

4 Status

Here you can update the individual’s status for the step. We’ll show you how to maintain the list of statuses when we talk about Editing Step Programs in the next section.

5 Step Note

Here you can add a Step Note to the step, to track details or record items for future reference.

6 Step Attributes

Any attributes applicable to the step will appear here. We’ll cover how to set up step attributes below.

While the Step Entry page is used for manually maintaining step information for individuals, there are automated alternatives. Steps can be updated from Streak Achievements or as part of a Workflow.

Bulk Entry

Often, you’ll need to add a step for a (sometimes very long) list of people. Luckily, that doesn’t mean you have to spend endless hours on repetitive data entry. The Bulk Entry page lets you quickly enter steps for a large number of individuals. You can access bulk entry for steps by clicking the icon from either the Step Program or Step Type pages.

In our Discipleship example we can use the “Pastor” attribute to record which pastor performed the baptisms. This is great if large groups are baptized by different pastors because you only have to select a pastor once for any number of individuals. We’ll cover how to set up attributes like this in the next chapter below.

Show on Bulk

If the Show on Bulk option is not enabled then the attribute will still appear in bulk entry, but it will need to be set for each person individually.

Editing Step Programs

Let’s go back to the Step Program page to see how we can edit our programs. Clicking the Edit button lets you update the program and its configurable settings.

1 Name

Provide the name of the program.

2 Active

Set the program to active or inactive.

3 Description

Add a description of the program.

4 Icon CSS Class

Choose the CSS icon to use for the program.

5 Default List View

Select either Cards or Grid as the default layout for viewing Steps on the Person Profile page (see the Default List View section below for full details).

6 Category

Categories help to group your related programs. You can view and manage step program categories from Admin Tools > System Settings > Category Manager using the Step Program entity type.

The step program configuration also includes settings for Statuses and Workflows. We will provide an overview for each of these in the following sections.

Default List View

Steps information for an individual can be viewed under the Steps tab on the person profile, either as cards or in a grid. You can toggle between these views from within the person profile using the and buttons. As noted in the prior section, the default view is set at the step program level.

The screenshots above (cards) and below (grid) are both for the same person following the Discipleship program.

While in card view, hovering over a card lets you view additional details as well as access the Step Entry page. This is controlled by the Step Type Advanced Settings (see Editing Step Types).

If you have multiple campuses, you can choose to show or hide the campus associated with a step by changing this block's settings. This applies to both the cards and grid views.

The default view doesn't have to be the same for all of your programs. Choose the one that seems best for each individual program. You can always change it later if you need to.

Statuses

The values you set up here are used to track an individual’s status for any step type in the program. This list shows each status and whether it is treated as Completing the step.

The Create Status page is used when adding or changing a status.

1 Name

Add the name of the status (e.g. In Progress).

2 Is Active

Set the status to active or inactive.

3 Is Complete

Select this option only if the status means the entire step has been completed.

4 Display Color

Select the display color for the status.

Workflows

Here you can add one or more workflows to the program. Keep in mind that workflows added to the program apply to all the steps in program, regardless of the step type.

The workflow can be launched according to one of three triggers:

• Step Completed: The workflow is launched when the step is assigned any “Is Complete” status (see Editing Step Programs).
• Status Changed: The workflow is launched either when there is any status change, or according to specific status changes you define.
• Manual: The workflow is launched by a manual click of a button.

See our Blasting Off With Workflows guide for more information.

Editing Step Types

From the Step Type page click the Edit button to change the step type settings.

1 Name

Provide the name of the step type.

2 Active

Set the step type to active or inactive.

3 Description

Provide a description for the step type.

4 Icon CSS Class

Choose the CSS icon to use for the step type.

5 Highlight Color

Choose the color to use for the step type.

6 Allow Multiple

Select whether the step can be completed more than once by the same person.

7 Spans Time

Select whether the step occurs over a period of time or in a moment of time.

8 Show Count on Badge

Select this option if you want the number of completions for the step type to be shown on the corresponding badge. See the Steps Badges section for full details.

9 Prerequisite Steps

Indicate if one or more other steps within the program should be completed before this step can be started.

10 Is Date Required

You can choose whether the date associated with a step is required or not. This applies to both Start and End dates if the step Spans Time.

The step type configuration also has settings for Step Attributes, Workflows and Advanced Settings. We will cover each of these areas individually in the following sections below.

Step Attributes

One or more attributes can be associated with a step type, using the page pictured below.

Assigning attributes to step participants is a great way to track details beyond whether a person simply started or finished a step.

We should pause a moment here to highlight the Show on Bulk option pictured above, which is described in the Bulk Entry section. Regardless of whether the Show on Bulk option is used, the attribute value can always be set for an individual from the Step Entry or Bulk Entry pages.

If you need more information on attributes in general, our Person & Family Field Guide has everything you'll need to know.

Workflows

We’ve seen how workflows can be added at the program level, but they can also be added to individual step types. As you might have guessed, the key difference is that workflows added to a step type will only be used for that particular step.

For additional details on using workflows in Steps, see the Editing Step Programs section. For every other detail you could imagine related to workflows in general, see our Blasting Off With Workflows book.

Advanced Settings

The Advanced Settings panel has options for customization and automation as described below.

1 Auto-Complete Data View

New steps will automatically be added and completed for the people in the selected Data View when the Steps Automation job runs. This job respects the 'Allow Multiple' and 'Prerequisite Steps' configuration options described above. If a person is found by the Data View, any currently incomplete steps of this type will be completed for them. If 'Allow Multiple' is not enabled for the step type, and if the person hasn't taken the step, then a new step will be added in a Complete status. If 'Allow Multiple' is not enabled, and if the person already has a Complete step of this type, then nothing will happen for that person.

2 Allow Manual Edit

If this is disabled, people will not be able to add or edit steps of this type from the Person Profile page. This does not prevent manually editing steps from within the step program pages.

3 Card Content Lava Badge

This is the Lava used to display the card content for Steps. See the Editing Step Programs section for additional details on cards. Generally, you shouldn’t need to make changes here.

Reporting on Steps

These charts aren’t the only way to get data from steps. Rock ships with data view filter types for steps, to use in reporting.

• Step Participants By Attribute Value: Lets you filter people records by the value of an attribute on the person’s step. You must provide a Step Program and a Step Type.
• Steps Taken: Allows you to filter people records according to their involvement in a step program. You can add criteria related to individual steps, or even start/end dates.
• Step Data View: You can create a Data View to return step entries, then use this filter to get all the people associated with those steps.

If you’re not sure about data view filters or how to use them in reporting, our Taking Off With Reporting guide has all the information you need.

In addition to data views, Rock v12.5 introduced a new StepProgramCompletion table. This table tells you when the person started and completed the Program by providing the earliest Start Date and, in many cases, the latest End Date across all completed Steps. Additional logic is applied when Steps have been repeated, to find the earliest appropriate End Date. A row is added for each time the person completes all Steps in the Program.

Occurrence Map Editor

Click on the Map Editor button to edit the occurrence map for the streak type.

When you add a new streak type the occurrence map will initially be blank as pictured below. The map can be populated manually through the editor, or it can be built from attendance data using the streak type Rebuild button (see Streak Type Rebuild).

1 Date Range Selection

Adjust the date range and click the Update button to change the dates you see in the bottom portion of the block.

2 Occurrence Map

This is where you’ll edit the occurrence map by picking which weeks (or days) should be included in the map. The Start Date for the streak type is 8/4/2019, so any weeks prior to that can’t be chosen. You also can’t select dates that are in the future.

When you update the occurrence map you’re changing the list of possible meetings. The most common reason to do that would probably be to remove dates where a regularly scheduled meeting isn’t taking place due to things like weather events. Removing dates from the occurrence map ensures nobody’s streak is broken for missing something that never actually took place. It's important to know that changes to the occurrence map will not be reflected in everyone's streak data in the blocks until the nightly cleanup job runs.

In our small group example we’ll manually select all of the 11 weeks that are available as pictured above. Any absences in any of those weeks will count against a person’s streak.

You might find it odd that the current week (or day) is not shown in the streak graph. Not to worry, we did this intentionally to avoid scaring anyone into thinking their streak had been broken, when in reality they simply haven't had a chance to engage this week. By default, streak calculations and graphs exclude the current day or week.

Location Exclusions

Click the Exclusions button from the Streak Type page to access the list of excluded locations. From this page you can add or remove excluded locations.

Just like excluding dates, you can also exclude locations. Excluding a location means a person’s streak won’t be broken if they missed an event or meeting at that location.

Streak Type Enrollment

Below the streak type detail block is the enrollment list block. Here you can see all the participants in the streak type and their streaks.

When you first create a new streak type the enrollment list will be empty. The list pictured below has individuals on it for example purposes only. We’ll review the block first, and then show you how to get individuals added.

1 Name

Individuals who are enrolled in the streak type have their names and photos listed here.

2 Recent Engagement

This graph shows the recent history of engagement for the individual. Our example is weekly, so each bar represents one week.

3 Current Streak

This column shows a person’s current streak, relative to today.

4 Longest Streak

This column shows the longest streak the individual has ever had.

5 Engagements

You can see the total number of engagements for the individual.

6 Enrollment Date

This is the date when the person entered the streak type. Absences and engagements prior to this date are ignored when calculating the person's streak.

There are two ways to enroll individuals into a streak type. We mentioned earlier that you can click the Rebuild button to add individuals from attendance records. We’ll look closely at that method in the Streak Type Rebuild section. The other method is to manually add a single person to the list.

1 Person

Find the person you want to enroll into the streak type.

2 Location

Select the person’s ‘home’ location to use for exclusions. If you have multiple campuses, you might want to track a person’s streak at one campus separately from the others.

3 Enrollment Date

Enter the date when streaks should start for this person. Absences and engagements before the enrollment date are ignored. You can think of this as being like the streak type Start Date, but for an individual person. You can't manually change the enrollment date after you save, so it's important to pick the correct date for the individual.

As soon as you save, you’ll be brought to the Enrollment Detail page.

Manual Tracking

We know from attendance records that Ted should have streak numbers higher than zero. But we’re taking the manual path, so we need to manually feed that into Ted’s streak data. Take a look at how the page changes after selecting the “Sep 29” week in the engagement map.

1 Engagement Graph

With an engagement manually recorded, now we have some streak data. You can see a blue bar has been added to the end of the graph to mark Ted’s recent involvement.

2 Longest Streak

We can also see Ted's Longest Streak count is now “1” instead of “0”. The Current Streak

is still zero because the engagement we added is in the past.

3 Engagement Map

Adding the selected week to the map is what updated the streak data noted above.

That’s the manual route for Ted. But what if you want to build streaks in a more automated way according to actual attendance records? As we mentioned earlier, you can do that by using the Rebuild feature.

Individual Rebuild

Let’s see how Ted’s data has changed after clicking the Rebuild button.

1 Engagement Graph

At the top of the block we see several new bars have popped up. From left to right, this graph shows:

• Five consecutive weeks of attendance (8/25 – 9/22)
• One week absent (9/29)
• Two consecutive weeks of attendance (10/6 – 10/13)
• One week absent (10/20)
• One week of attendance (10/27)

2 Streak Data

As a result of the rebuild, the Current Streak and Longest Streak were both updated from Ted's attendance records.

3 Enrollment Date

Notice that Ted's enrollment date was changed from 9/1 to 8/4 by the rebuild process. There are two reasons why 8/4 was chosen. The first is that Ted has attendance data going back to June, so the rebuild process knew his enrollment date should be earlier than 9/1. The second reason 8/4 was chosen is because individual streaks can't go any earlier than the streak type start date, so Ted's attendance prior to 8/4 is ignored.

4 Engagement Map

When building from attendance data, you’ll see three different types of date selections in the engagement map:

• Selected, Editable: Weeks where Ted has small group attendance data have been selected with a checkmark (e.g. “Sep 08”). You can manually remove these engagements from the streak data by unchecking these boxes.
• Not Selected, Editable: In this example Ted didn’t attend the weeks of “Sep 29” or “Oct 20” so they are not selected. You can manually add engagements to streak data by selecting these boxes.
• Not Selected, Not Editable: This applies to dates before the person’s enrollment date, or dates in the future.

If you analyze Ted's streak closely, you may notice an unexpected gap. The rebuild process found attendance data going back to at least 8/4 and set Ted's enrollment date accordingly. But if Ted has attendance data going back that far, then why do his engagement graph and Longest Streak both start at 8/25? Weeks prior to 8/25 are being ignored because we didn't include them in the streak type occurrence map (see Occurrence Map Editor). If we went back to the occurrence map and selected those additional weeks then Ted's attendance data for those weeks would be reflected in his streak data.

What if we want to include Ted's attendance data from June and July? We've already established that this streak can't go any earlier than 8/4 due to the streak type start date, and that the start date can't be changed. So, at this point, if we want to include earlier attendance we'll need to rebuild the streak type. Aside from creating an entirely new streak type, rebuilding is the only way to alter the start date. We'll cover what that looks like in the Streak Type Rebuild chapter.

Exclusions

Looking closer at the Engagement Map Editor, we can see Ted didn’t attend the week of September 29th. We know Ted’s car broke down in a storm that week, and we’re feeling generous, so we’ve decided to ignore that absence in Ted’s streak data. All we need to do is select the "Sep 29" week in the exclusion map and click the Save button. Now it’s like the absence never happened.

1 Engagement Graph

The graph accurately reflects data from attendance records. Ted’s absence still exists even though we excluded it from his streak data.

2 Longest Streak

Ted’s longest streak is now "7" even though we can see from the engagement graph that he never actually attended seven times in a row. The exclusion doesn’t count toward the streak, but it also doesn’t break the streak.

3 Engagement Map

Like the engagement graph, we can still see that Ted didn’t attend the week of "Sep 29" because it isn’t selected in the engagement map. This is accurate according to attendance data.

4 Engagement Exclusion Map

Selecting "Sep 29" triggered the updates in the above points. If anyone were to question the discrepancy between attendance and streak data, it’s clear here that a week was manually excluded.

Achievement Types

Let’s look at an example achievement type with some data already added, so you can get an idea of what to expect. In this example we’re tracking an achievement that’s earned when a person has attended three times consecutively. In later sections we’ll go into the details and cover how this all gets set up.

1 Successful Attempts Graph

This graph shows the number of successfully completed attempts toward this achievement type. Like other graphs in Rock, you can adjust the timeframe that’s displayed. The graph won’t appear if there’s no achievement data at all, or if there aren’t any successful attempts within the selected timeframe.

2 Edit / Delete

The achievement type can be edited or deleted using these buttons. You can edit any of the achievement type’s setup except for the Achievement Event. See the Adding Achievement Types section for full details.

3 Rebuild

If you’ve already read the Individual Rebuild or Streak Type Rebuild sections, then you’re familiar with the concept of rebuilding. Achievement types also have a rebuild feature, which works in a similar way. Clicking the Rebuild button from the Achievement Type page causes attempt data that occurs after a person's most recent successful attempt to be deleted and rebuilt.

4 Attempts

Each person’s attempts at the achievement type are listed here. This block provides several important details for each attempt, covered in the points below. We’ll take a deeper dive into viewing and managing attempts in the Achievement Attempts section below.

5 Start Date

This column indicates the date on which the person started the attempt. For instance, if your achievement type requires three engagements in a row then this would be the date of the first engagement.

6 End Date

This column indicates the date on which the attempt ended. For instance, if your achievement type requires three engagements in a row, then this would be either the date of the third engagement or the date on which the streak was broken.

7 Successful

A checkmark in this column indicates a successful attempt, which means the person satisfied the conditions of the achievement type. If there’s no checkmark here, it either means the attempt wasn’t successful (a checkmark appears in the Closed column) or is still in progress (the Closed column doesn’t have a checkmark).

8 Closed

An attempt is closed when the person has either succeeded or failed in their attempt at the achievement. For instance, if your achievement type requires three engagements in a row, then the attempt would be closed when the third engagement is registered or when the streak was broken.

9 Progress

The progress bar reflects how far along the person is (or was) toward successfully earning the achievement. The percentage complete can exceed 100% if the achievement type has Allow Overachievement enabled, which we'll discuss below.

Adding Achievement Types

To get started with achievements, navigate to People > Engagement > Achievements. You’ll be brought to the Achievement Types page pictured below.

From here you can add as many achievement types as you want or look at the attempts for an existing achievement type, as described in the prior section. Let’s look at what makes an achievement type work.

1 Name

Provide a name for the new achievement type.

2 Active

The achievements will be tracked only if the achievement type is Active.

3 Description

Some achievement types will be similar, so be sure to provide a description that will help identify what makes this one unique.

4 Category

You can optionally assign a category to help group and organize your achievement types. When creating a new category (System Settings > Category Manager) for achievement types, be sure to select “Achievement Type” as the entity type.

5 Allow Overachievement

If enabled, this setting allows you to track how much someone has exceeded the conditions of the achievement type. For example, if your achievement type requires someone to attend three times in a row, and if someone attends six times in a row, you’ll see that they have 200% progress toward the achievement.

6 Max Accomplishments Allowed

Use this field to limit how many times the achievement can be accomplished. For example, if your achievement type requires someone to attend three times in a row and they attend six times in a row, they can earn the achievement twice. Leave this field blank to allow an unlimited number of accomplishments. This should be set to “1” before enabling Allow Overachievement.

7 Icon CSS Class

You can optionally assign an icon to the achievement type, to help distinguish it. This will be used as the achievement’s badge icon in most cases (see below for details).

8 Achievement Event

Achievements can be earned in several different ways. Here you’ll select what kind of event this achievement type will use. This can’t be changed after it’s saved.

• Steps: Program Completion: Select this if you want to have an achievement for someone who has completed all of the Step Types within a specified Step Program.
• Interactions: Accumulative: This is used to track achievements based on Interactions. You can track the achievement based on a person having any kind of interaction, or you can get more specific by selecting an Interaction Channel and Interaction Component to reference.
• Streaks: Accumulative: The achievement is earned by engaging a specified number of times, regardless of whether or not those engagements are consecutive. Use this setting if you want to track that someone has engaged 50 times in a year.
• Streaks: Consecutive: The achievement is earned by engaging a specified number of times in a row. The key here is that the engagements must be consecutive (i.e. an unbroken streak) to earn the achievement.

9 Number to Achieve / Accumulate

The name and function of this field will change according to the Achievement Event setting. Think of this as the goal that the person must reach to earn the achievement. In this example the Number to Achieve is set to “3” because this achievement is earned by people who have attended three times in a row.
If Allow Overachievement is enabled, then this number marks 100% progress. If Allow Overachievement isn’t enabled, then this number marks successful completion of the achievement.

10 Timespan in Days

Provide the number of days in which the number of engagements (Number to Achieve / Accumulate) must occur to successfully earn the achievement. In this example the achievement will only be earned if the person has engaged three times within any 30-day period.

11 Start Date / End Date

These dates establish boundaries for when events can count toward the achievement type. Events before the Start Date or after the End Date are ignored. For instance, if you’re using achievements to track Step Program completion, only people who completed the Step Program within the provided date range will earn the achievement.

12 Step Configuration

That’s right, achievements can be used in step programs. We'll look closely at this area and how it works in the Step Configuration section below.

13 Advanced Settings

In the Advanced Settings you can add Prerequisite Achievements, launch workflows and design achievement badges. Check out the Advanced Settings section below for full details.

Achievement Attempts

Now that the Achievement Type is set up, we can start tracking attempts. Attempts, as you might have guessed, are instances of individuals trying to meet the conditions of the Achievement Type. Although there isn’t a formal “status” for attempts, they can be thought of as either successful, unsuccessful or in progress.

If the person satisfies the achievement type’s conditions, then the attempt is Successful. If the person fails to meet the conditions, then the attempt is not Successful. If the person is in the middle of working toward the achievement, then their attempt is in progress.

Even though achievements are automated, you can add or change individual attempts manually from the Achievement Type screen. Simply click on the attempt row for a person and then click the Edit button. Manual adjustments should be rare but may be needed occasionally due to unusual circumstances or overrides.

1 Start Date / End Date

You can manually change the Start Date and End Date values for the attempt being viewed or added.

2 Progress

Changes here will be reflected in the progress bar for the attempt. A value of “.5” indicates 50% completion. A value of “1” reflects 100% completion and will count as a successful attempt.

Step Configuration

No, you haven’t jumped to the wrong section in the manual. Rock lets you add step data automatically using achievements. You can access the configuration described below when creating or editing an achievement type.

1 Add Step on Success

The step features for the achievement type will only work if the achievement type has this option enabled.

2 Step Program

Select the step program to which a step should be added. After selecting a step program, the Step Status and Step Type fields will appear.

3 Step Type

Indicate the Step Type that should be added to the person’s record.

4 Step Status

Choose the status that should be applied to the step when it’s added.

The date on which the achievement was completed successfully will be the date used for adding the step. The date may be used as the step’s start or end date, depending on how the step type and achievement type are configured.

The conditions you’ve configured for your step types will still apply when steps are added from achievements. Steps with prerequisites won’t be added if the individual hasn’t completed the required prerequisite steps. If an achievement is earned more than once it will only add multiple steps if the step type allows multiple completions.

Advanced Settings

You can access the advanced settings while creating or editing an achievement type. As described below, you can use this configuration to do things like create achievement badges or add prerequisite achievements.

1 Prerequisite Achievements

You can optionally specify other achievements that must be earned before this achievement can be earned. The other Achievement Type must already be configured in order to be selected.

2 Workflow Launch

Achievements can be thought of as having three different states. An individual has either started an achievement, successfully finished it, or failed to finish it. At each of these points you can launch a specified workflow.

3 Badge Lava Template

If you provide a template here, it will be used for the badge wherever the badge (of type 'Achievement') is displayed. If there’s no template here then the achievement’s icon will be used for the badge, except for Step Program Completion which uses the step program’s icon. If there is no template here and no icons configured, the default icon is used for the achievement’s badge.

4 Results Lava Template

Like the badge, you can create a Lava template to display the achievement results elsewhere in Rock. Currently Rock doesn’t ship with a dedicated place to display achievement results, but stay tuned because we’ll be rolling out additional features for this in future releases.