What Makes Up a Report?

There are two facets to any report: filter and display criteria. Consider this example. Your organization's leader walks in your door and asks for a list of attendees over the age of 18 who began attending within the last two years. They would like to have the names, contact information and the number of times they have attended. Using this example, let's look at each of the facets of reporting.

1. Filter Criteria: These are the criteria that limit the results to display. They answer the "Who" part of the request. In the case of the example, the criteria would be:
   1. Attendees
   2. Greater than 18 years of age
   3. Began attending in the last two years
2. Display Criteria: Once the results are filtered you must display them, with the necessary attributes, to the person using the report. In the case of our example, these attributes might be:
   1. Name
   2. Phone
   3. Email
   4. Address
   5. Number of Times Attended

Once you create your handy report for your leader, it's very likely they'll be back asking for further changes. Perhaps now they want another report with the same logic but only showing females. In most systems you'll have to start over and make a copy with the addition of the new criteria. Now you have two very similar reports to maintain.

With Rock, we have deliberately chosen to split the filter and display activities in reporting. You create your filters by defining Data Views. You then create your display by creating Reports that use the Data Views.

Reporting Strategy

The strategy part of reporting comes from the definition of your Data Views. It will be tempting to quick-write a very specific data view for each report. Consider, though, that data views can extend and build off of each other. For instance, you might create a data view that filters Adult Members & Attendees and then create a new data view that uses this view and adds the criteria of female gender. You’ve now created two views that can be used for the report at-hand AND in future reports. What’s more, if you ever need to redefine what makes an Adult Member & Attendee, you can change it in one place and all reports that are built off of that view will get the new definition. These two data views are available out-of-the-box with Rock. Consider the results of these views on the Rock sample data in the figure below.

Before starting any report, you should ask yourself:

• What, if any, criteria filter in this report might be reusable in future reports?
• What data views have I already defined that I can start with for this report?

Don't worry - we've only scratched the surface of Rock's tools. Now let's get our hands dirty learning about creating data views and reports as well as learning about Rock's other reporting tools.

Age Classifications

Speaking of the ages of individuals...Rock allows for simple and quick filtering on whether an individual is an Adult or a Child using the Age Classification property. This property is available as a Person filter type when creating Data Views and as a Field Type when creating Reports (more on that in the next chapter). In Rock, an adult is anyone over the age of 18 or marked as an adult in one or more families. A child is anyone less than 18 or a child in all families. If neither of these conditions are met, the individual is marked as Unknown. Rock calculates age each time a person is saved and re-calculates it every time the Rock Cleanup job is run.

Any vs All

At the top of the filter group, you’ll notice a setting that says Show if Any/All of these are true. You might be wondering what’s the difference between Any and All. Let’s define each:

• All: This means that each of the filter criteria must be true in order for a record to be displayed. One helpful trick is to read through each filter and insert the word and in between each. So, for a record to display in the Adult Members & Attendee view, a record must: have a record status of active AND a connection status of member or attendee AND must be an adult in a family.


• Any: This setting means that if Any of the filter criteria is true then display the record. It's like inserting the word OR between each criterion.

Filter Groups

For complex views you may need to include both AND and OR type logic into your view. Filter groups give you this option. Say for instance you need to create a view that shows individuals who are married AND a member OR who are single AND an attendee. That data view would be configured like this:

Note how we have two filter groups where if Any of them is true the record is selected. They in turn have criteria that must All match.

Post-Filter Transformations

The Post-Filter Transformation gives you the option to "flip" the results of a Data View with ease. For example, if your Data View includes the kids attending summer camp, selecting the Parent transformation will find the parents of those kids. If your Data View includes Adult Members & Attendees, choosing the Children transformation will give you the children of those selected. To provide as much flexibility as possible, Rock allows you to transform data views by applying the following transformations:

• Allowed Check-In
• Allowed Check-In Children
• Children
• Family Members
• Father
• Giving Leader
• Grandchild
• Grandparent
• Head of Household
• Mother
• Parents
• Spouse

Securing Data Views

There will be Data Views that you want to limit access to. Note that you can control who has access to Data Views. To change the default security on a Data View, click the button on the data view details screen.

You can also check the access for Data View categories. This allows you to modify the security for all Data Views in that category.

Taking Security Further

Controlling who has access to Data Views is important. But you also need to limit who can make new Data Views with certain criteria. You can limit what filters are available to specific people and groups under
Admin Tools > Settings > Data Filters. Here you'll see a list of available filters with the ability to change who has access to use each filter.

When filtering on the attributes of an entity (like person attributes), normal attribute security will be used in controlling access.

You can also control security on the Data View transforms. This can be configured under
Admin Tools > Settings > Data Transformations.

Persisting Data Views

Sometimes when you have an extremely large or complex Data View, it can take a long time for Rock to filter down to just the records you're interested in. This can be critical when you're relying on the information in the data view for reports, for workflow actions (using Lava) and just to keep the load on your server as low as possible. This is especially true when you have data views referencing several other data views.

Persisted Data Views to the rescue! If Persistence is enabled, Rock will only calculate the records in the list as frequently as you specify. That means that when you click on the data view, Rock already knows what records are in the list and can provide them extremely quickly. (Calculating the contents of persisted data views is what the Update Persisted Dataviews job does, in case you were wondering).

When you persist a Data View, keep in mind that the statistical data (Time to Run, Runs Since, and Last Run) may not update as frequently as you'd expect. These values usually change only when the Data View's results are updated, not when the persisted results are being used. In other words, retrieving data from a persisted Data View doesn’t require it to be re-run, so the run statistics aren't always updated. Most of the time, the Data View will only be truly re-run when the job recalculates its contents, and that’s when you can generally expect the statistics to change.

Since Rock isn't calculating the contents of these Data Views every time you load it, that does mean that the list might be out of date by up to the interval you specify. For instance, let's say that you have a very involved data view that, among other requirements, requires that the people in it are members of a certain group. But it's such an involved data view that it takes quite some time to load, so you set a Persistence Interval of "2 Hours". If Ted Decker matches all of the filters, then he will show up in the Data View when it's calculated, as expected (along with anyone else who matches all the filters). Now, if Ted leaves the group that you have to be a member of to be included in that Data View, it's possible that he will continue showing up in that Data View for up to two hours; the next time that persisted Data View will be re-evaluated.

Usually, it's not extremely important that your Data Views be absolutely accurate up to the second, so that might not be a big deal. But if you're relying on a data view for something that needs to truly reflect the absolute latest data, then you should leave the Enable Persistence setting disabled.

Nested Persisted Data Views

Now, let's look deeper at nested Data Views and how it works when they're persisted. Let's say that we make "Adult Member & Attendees" a Persisted Data View - it's going to be calculated every two hours. Let's also say that we have another Data View that has a filter that specifies that the people must also be in the "Adult Member & Attendees" Data View. (Usually, you'd have other filters as well, naturally). It would look something like this:

Since "Adult Member & Attendees" is now persisted and only calculated every two hours, then whenever you load a Data View that references it (with "Use Persisted" selected as shown) the list of Adult Members and Attendees might be as much as two hours old. Hopefully nobody stopped being a member/attendee that quickly, but if they did, they could continue showing up in this Data View until the next time the nested Data View is calculated.

Put another way: if a Data View has persisted child data views, it will use the persisted version of the child data view if "Use Persisted" is enabled.

In general, it would be much faster to persist a data view if "Use Persisted" is enabled on its child data views. However, its accuracy is limited to the child data view that had the longest "Persistence Interval".

Creating A Report

Let's jump right in and take a look at a report. For our example, we'll look at a report that gives the name and phone numbers of individuals with duplicate phone numbers. The figure below shows what this report would look like. The callouts for the figure explain the various steps used in the creation of our report.

1 Name / Description

First, we give our report a name and description. We highly recommend that you spend some time writing a clear description that tells what the report does and how it should be used.

2 Applies To

Next, select what type of entity you are writing a report for. In most cases this will be Person but, like Data Views, you can report on anything.

3 Data View

Now that you have selected the entity, you'll see a list of Data Views you can use as the source for your report.

4 Sorting

You can sort your report by any field you add in either ascending or descending order. You can even choose to sort on more than one field at a time.

5 Resulting Row Limit

If needed, you can limit the number of records that are displayed on your report.

6 Fields

Finally, you'll add the fields you want to display on your report. You can determine for each field whether or not you want it to display in the grid. You might be thinking, "If it's not on the grid where else would I see it?" If you don't check this button, the field will still be available when you export the report to Excel from the bottom of the grid. This is helpful for supporting information that is not needed very often.

The Power of Lava

You'll notice that one of your field options is Lava. Lava is a templating engine that allows you to customize the way data is presented. With this field type you can mix and match data in lots of different ways.

Below are a few examples:

Last Name, Nick Name

{{ LastName }}, {{ NickName }}

Last Name, Nick Name as a link to the ‘Person Profile’ page

<a href="/Person/{{ Id }}">{{ LastName }}, {{ NickName }} </a>

If baptized, show field as a checkmark

{% if BaptismDate != null %}
    <i class="ti ti-check"></i>
{% endif %}

For some fields (like Phone Number), use the dot notation to get the property you want

{{ Phone.NumberFormatted }} unlisted: {{ Phone.IsUnlisted }}

Let's pull this all together: this setup would create a report where the person's name links to their profile, and display a check mark if they are baptized:

We should point out that usually you could simply use the stock Person Name field to create a linked name formatted this way, without using Lava. But if you wanted to link to an alternate person profile page, this would give you full control over doing that.

You can find out more about Lava on the Rock RMS learning website.

If you want more information on using Lava in merge documents, you'll find that in the Rock Admin Hero Guide.

Persisted Data Views in Reports

As you'd expect from our earlier discussion, if your report is based on a persisted Data View, the report should display much more quickly than if the Data View wasn't persisted. That's because it's not having to figure out which rows to display- that's already been calculated, so it'll just use that list.

And if your report is based on a persisted Data View that also references other Data Views, it doesn't actually matter (at the report level) whether those nested Data Views are persisted or not. That's because the "top level" Data View that the report is using, is persisted. So, it's not actually having to go and look up those nested Data Views at all in order to generate the report. Neat, huh?

Securing Report Data

It’s important to know that anyone with access to a report will be able to view all the data in that report. This includes data they wouldn’t normally be able to access elsewhere in Rock. In effect, report data bypasses the person’s security rights. That might sound alarming at first, but don’t worry. Rock was intentionally designed this way, and we have some suggestions for securing your data.

First, you might be wondering why security is not applied to report data. If Rock were forced to apply a person’s security to the rows returned in a report, there would be two problems:

1. Sometimes you want to bypass security for valid reasons. For instance, let’s say you have a report that lists people who have donated to your organization so you can send handwritten thank you cards. This report doesn’t show specific gifts but does use giving data to list the individuals. The person tasked with writing the cards probably doesn’t have access to financial data in Rock. If the person’s security were applied to the data in the report, the report would not give them results because it references financial data. Now they can’t do their job and the only solution is to give them security they don’t need.
2. Performance. Let’s say your report provides a list of group members and their group. If security were enabled, the system would need to run a security check for each row in the report to see if the person viewing the report has access to the group. Remember, the security on a group is hierarchical on group structure, group member role and on the group type. All of those areas would need to be evaluated. You can see how quickly this adds up, even to the point where the report will time out before results can be returned.

So, what should you do?

It starts with the report’s author. The author is responsible for considering the security of the data they’re providing. However, keep in mind that security is enforced at the time of authoring. For instance, when building a data view the author can’t exclude groups that they don’t have access to. If group data is displayed in the report, then those groups will appear on the report, which might not be desired.

Also, don’t forget you can apply security to the reports themselves. Limiting access to the report ensures the data it contains can only be viewed by the intended individuals.

Another approach is to look for configurations outside of reporting that might provide the security you need. For instance, if there is a certain type of group you’re concerned with (like a recovery group) make sure those groups are all of a specific group type. Then you can “apply security” by limiting the group types shown in your report. You’re not actually doing anything with security but adjusting your configuration in this way can help ensure sensitive data stays secure.

As you can see, planning is important in developing data views and reports. You want to ensure that the individuals who can view the report are identified, and that provisions are made so that sensitive information does not inadvertently leak.

Create Data View

The first step is to create the data view under Tools > Data Views that will drive the report. Here we have a few filters: campus and our background check logic. Notice that we leave the campus blank. This basically says, "show any campus," which will be our "default."

Create Report

Next, we create the report under Tools > Reports. Here we add in the columns we’d like to display on the report. Nothing new here.

Set Up Dynamic Report

Finally, we’re ready to add our Dynamic Report block. After creating a new page and adding the block, we can set the block's settings. Below is a screenshot of what's possible.

1 Results Title

The title text to use for the results grid.

2 Results Icon CSS Class

The CSS icon to use for the same grid.

3 Filter Icon CSS Class

The CSS icon to use for the filter panel.

4 Filter Title

The title text for the filter panel.

5 Report

The report we created in step 2.

---

Filters:
After selecting a report, Rock will look at the data view for that report and list its filters. Each filter includes the following options:

6 Filter

The data in "Filter" is what can usually be used in a URL parameter to pre-set a filter where you'd type text. For instance, a "First Name" field might show a filter of Property_FirstName, in which case a URL like /page/123/?Property_FirstName=Ted would pre-fill and pre-filter the report for people with a first name of Ted. Note that Campus and Campuses are special cases; since these aren't text boxes, try using ?CampusId=1 or ?CampusId=1,2 to set these.

7 Options

For each filter in your Data View, you'll be able to configure these options which control whether the person using the report can specify which filters are used:

• Visible: This tells the block whether the filter should be shown to the person for them to modify. In our sample we're only letting them change the campus, so only the campus filter would have this checked.
• Configurable: Determines if the person should be allowed to modify the criteria of the filter. At first you might think this odd, as when would you ever not want to allow the criteria to change, but it'll make sense when combined with the next option.
• Toggle Filter: This setting will show the filter with a checkbox next to it. Unchecking the box will disable the filter entirely.

8 Pre-HTML

This is HTML which will be shown before the filter option at the top of the Dynamic Report block. You can use this to group controls together in a well, or change their widths using Bootstrap classes, for instance.

9 Label

The text you put here will determine what title the person will see associated with the filter. The default value of {{ Label }} will display the title of the filter from the source Data View filter.

10 Post-HTML

This is HTML which will be shown after the filter option at the top of the Dynamic Report block. You can use this together with PreHTML to create some neat effects and change the layout of your filters.

Extra Power from Stored Procedures

OK, we're going to geek out here for a second... By using SQL Server Stored Procedures, it can get even more powerful. When calling a stored procedure, you can pass the procedure any of the query string parameters from the URL. For instance, if the page the block is placed on is accessed from the URL:

https://<your server>/page/123?GroupId=12

You can pass the value of the GroupId to your stored procedure as a parameter. The stored procedure can then use this value to help return relevant data (say group members for the group).

You can also pass in the current person's person Id field. This allows you to further personalize the data to the person requesting the page. Just think of all the fun you can have with this block!

In order to make this all work, you'll need to define each of the parameters you want passed to your stored procedure in the Parameters field discussed above. Rock will look for each of these parameters in the URL’s query string and, if found, pass in the value to the procedure. If you would like the current person’s Id to pass in, you'll likewise need to add in the parameter CurrentPersonId.

Configure Block Settings

When the block is first added to a page it won't have any functionality until it's configured. The block settings you'll use to do this are described below.

1 Block Title Settings

Similar to other blocks, you can customize the options for the block's title area using the fields provided.

2 Filter Button Text

By default, the button to apply the filter is labeled as "Filter" but can be customized to your liking.

3 Filter Button Size

The size of the Filter and Reset Filters buttons can be changed here. The default value is "Extra Small", but you can also select "Small" or "Normal" to make the buttons slightly larger.

4 Filters Per Row

This setting controls how many filters are displayed in a single row within the block. This doesn't impact anything if you have only one filter.

5 Filter Selection Action

This setting determines what happens when a non-textbox filter is selected:

• Do Nothing: No changes occur automatically. The viewer must manually click the filter button to apply their selections.
• Update Filters: Filters whose available values depend on the selected values of other filters will update automatically, but the viewer must still click the filter button to apply them. This is useful when filters rely on virtual page parameters This is useful when filters rely on selected values from other filter (via virtual page parameters). If Enable Legacy Reload is enabled, page parameter changes will appear in the query string instead of being virtual (i.e., invisible).
• Apply Filters: All filters are applied instantly, without the need to click the filter button.

6 Redirect Page

If you provide a page here, the person will be redirected to that page as soon as they click the Filter button. The URL for the target page will include page parameters for the selected filters (see next section for details).

7 Show Filter Button

If enabled, the Filter button will be visible. Typically, you'll only want to hide the button if the Selection Action (see below) is set to Update Page.

8 Show Reset Filters Button

You can choose to hide the Reset Filters button if needed. This will keep the filter's information in the URL after it has been applied.

9 Enable Legacy Reload

If enabled, a full page reload will be triggered to apply the filter selections (helpful when using this block to drive the behavior of non-Obsidian/legacy blocks on the page). If disabled, the filter selections will be communicated directly to any Obsidian blocks listening for these filters, so they can respond accordingly.

10 Filters

This is where you'll add the filters that should be available for selection in the block. Adding filters to this block is like adding attributes to an entity. We'll look more closely at an example in the next section below.

Adding and Using Filters

If you've ever added an attribute to a person, group or other entity, then you're already familiar with adding filters to this block. As pictured below, these filters use many of the same fields as attributes.

The Key value you choose for the filter will appear as the name of the parameter in the URL after the filter is applied. You'll need to reference this value later, so try to pick something unique and descriptive.

In the example pictured above we've added a filter with a field type of "Connection Opportunity". As a result, a person accessing the page will be prompted to select a specific opportunity. We're only using a single filter here, but you can add as many filters as you need. Each filter functions independently from the others, so you can use a variety of different field types.

Now that a value has been selected the person should click the Filter button to apply it. Depending on your setup, the Filter button will do different things. It might redirect the person to a new page, or it could cause data to change in another block on the same page. In any case, it will update the URL with the filter's Key and the value of the person's selection.

Using our connection opportunity example, you can see below how the Key ("ConnOpp") and the GUID (of the "Greeter" opportunity) have been added to the URL.

Before:
https://rocksolidchurchdemo.com/page/123

After:
https://rocksolidchurchdemo.com/page/123?ConnOpp=6A7935B2-A97D-4F9D-82B3-4F835533325F

If you configured the block to redirect people to a different page, then the filter information will be appended to the URL of the target page in the same way. This can be very useful if the target page has a block that expects this information to already be in the URL, which won't happen until after the person clicks the Filter button.

Page Parameters and Lava

When combined with Lava, this block becomes a powerful tool that can be used in a variety of ways. All you need to do is add {{ 'Global' | PageParameter:'ConnOpp' }} to a workflow, report or anywhere else Lava is used. Just replace "ConnOpp" with the Key for your filter, and the doors are open.

Some blocks, like the HTML Content block, will need to have the RockEntity command enabled for this Lava to work. Pictured below is a basic example of an HTML block using the GUID of a connection opportunity to display the number of requests in the opportunity.

See our Lava documentation for more information.

Anatomy of a Metric

Metrics are defined with categories, very similar to data views and reports. This allows you to organize them in a way that makes sense for your organization. One thing that is unique about metrics is that they can be linked to more than one category. This allows you to re-use them in several areas of your metric hierarchy.

So how do we create a new metric? Administrating metrics is done under Tools > Metrics. For our example we'll create a new metric that displays the number of adult members and attendees we’ve had each week. Here are the details of the completed metric with callouts for each field.

1 Schedule and History

At the top of the page, you can see the current schedule this metric is running on, and the last time the Metric was run.

2 Title

Be sure to provide detailed titles for your metrics that not only make sense to you, but also to those who will be using these metrics in the future.

3 Icon CSS Class

The CSS class of the icon you wish to associate with the metric. This is used in the display of the metric. Rock uses the Font Awesome icon set by default, but any CSS based icon set can be used if properly configured.

4 Subtitle

The subtitle will be shown on graphs and charts.

5 Description

You'll be tempted to just skip right over this field, but you'll regret that in the future. No matter how obvious you feel this metric is, future you is screaming for you to add details about what is being measured, how it's calculated, any filter specifics (like only members), etc. Be kind to future you and document as much as you can. When you're done, go ahead and thank yourself ahead of time.

6 Metric Champion

One of the keys to good metrics is good documentation. In that regard we’ve worked hard to be sure that metrics become self-documenting. The metric champion allows you to note the person in your organization who is responsible for confirming that this metric is meeting its goals.

7 Metric Administrator

The metric administrator is the individual in your organization who is responsible for ensuring that the metric data is entered correctly and is valid.

8 Categories

This field allows you to link your metric to one or more categories.

9 Measurement Classification

Classifies the metric, to ensure it’s known what the metric is measuring. For instance, the Total Weekend Attendance classification would be tied to the single metric that’s used for tracking total weekend attendance. This enables the system to utilize these metrics for analytics. See below for additional details.

10 Units Label

The y-axis label describes the units of what is being measured (people, groups, money, etc.)

11 Cumulative

Some metrics make sense to compare year-to-date, others - not so much. For instance, it's often helpful to look at year-to-date values for adult members and attendees. But a metric that tracks attendance for a service or event often does not make sense to evaluate the same way. This field allows Rock to know if cumulative comparisons make sense for this specific value.

12 Unit Type

Metrics can track different types of data, so you can use the Unit Type setting to tell Rock you're working with numbers, currency or percentages. What you choose here will determine how the metric values appear in different areas, like on the metric's chart. For instance, if you select Percentage then the y-axis on the chart will show 10%, 20%, etc.

13 Enable Analytics

Check this box if you want the metrics to be made available for use by analytic tools such as Power BI.

14 Source Type

The source type defines how the metrics will be entered into the system. The options are:

• Manual: Metric values will be entered in manually.
• SQL: A SQL statement will be run to populate the values. Once you select this option a SQL entry input will be displayed. The help menu for the SQL field provides in-depth information on how your SQL should be formatted.
• Data View: A data view will be executed, and the count of its values will be added to the metric with the date it was run. The help field here also displays information on configuring your data view.
• Lava: Lava will be used to generate the values. When you select this option, a Source Lava field will be displayed. This is where you add your Lava code. The help menu offers examples of Lava that could be used for metrics. To learn more about Lava, go to https://community.rockrms.com/lava.

15 Schedule

The metric schedule helps determine how often this metric is calculated. When used with the SQL, Lava and Data View source types, this field will actually tell Rock when to automate the harvesting of metric values.

16 Auto Partition on Primary Campus

Data View source types don't support partitions, with one exception. If your data view returns people, and if you only have a single Partition of type Campus, you can select this option to have the metric return people by campus.

17 Series Partitions

For simple metrics you're done, you can skip this section. Often times though you want to break your metrics down by campus, or maybe campus then service time. Setting up series partitions allows you to do just that. You always get the date partition (that's free), but you can set up as many partitions as you feel necessary (but more than two can get a bit complex).

Measurement Classifications

Measurement Classifications help Rock unlock deeper insights from your metrics by adding meaning and context to the data they capture. Each metric in Rock can be assigned a specific classification that indicates exactly what that metric measures. For example, you might classify a metric as "Total Weekend Attendance" to give Rock a clear, consistent understanding of that data point across all systems.

The Measurement Classifications that ship with Rock are listed below:

• Total Weekend Attendance: This metric measures the total weekend attendance for the organization, partitioned by campus and schedule.
• Volunteer Attendance: Measures the number of volunteers that served for the given week. Partitioned by campus and schedule.
• Prayer Requests: The number of active prayer requests for the given week. This metric should be partitioned by campus.
• Prayers: The number of prayers for the given week. This metric should be partitioned by campus.
• Active Families: The number of active families in the given week. This metric should be partitioned by campus.
• Baptisms: The number of baptisms in a given month. This metric should be partitioned by campus.
• Giving: This metric represents weekly giving. It's up to you to define the financial accounts that make up this metric. This metric should be partitioned by the campus of the financial account. Review the account list in this metric to decide if you want to modify the @Accounts variable.
• eRA Weekly Wins: Tracks the number of individuals who attained eRA status within the current week. This metric should be partitioned by campus.
• eRA Weekly Losses: Monitors the number of individuals who exited eRA status in the current week. This metric should be partitioned by campus.

Using one metric for each classification ensures that we have a single, reliable source of truth for critical data like attendance or giving. This accuracy allows Rock to automate tasks, create reports, and even generate future features that draw directly from your specific metrics, tailored to match what each metric represents. Without Measurement Classifications, Rock could only see raw data points. Now, it knows what each one means.

To use Measurement Classifications effectively, select the correct classification for applicable metrics and be sure to configure your metrics precisely as specified. Each classification is associated with a Defined Value, which outlines essential configuration requirements for that metric. Think of these requirements as a blueprint. They help ensure the data tagged with a classification fits consistently within Rock’s framework. If a metric doesn't exactly match these requirements, it shouldn't carry the classification, since even small discrepancies could lead to inaccurate results.

Entering Metric Values

There are two types of metric values you can enter. Each one is discussed in detail below.

1Type

The first entry denotes if this is a measure or a goal. More on the difference between these two below.

2Value Date

The date that the value is for.

3Series Partitions

If you configured any series partitions, you'll need to select their values here. In this example there are partitions for Campus and Service.

4Value

The metric measure or goal value.

5Note

A note for the value. This is a great place to document special outliers (like Christmas or Easter) or additional data (like the week's sermon title).

Metric Charts

The easiest way to view metrics values is to look at the charts that appear above the metric definition. This will show you all of the values entered for the metric. You can edit the Metric Detail block's settings to change what the chart shows and how it looks.

If you would like to have more options for displaying metrics, take a look at the Metrics Dashboards chapter below.

Service Metric Entry

You'll often have the need to enter metrics that follow the partition pattern of "Campus > Sunday Date > Service Time". We've created a simple entry page for you to enter these types of metrics into. You'll find this page under Intranet > Weekly Metrics. Click the drop-down menus along the top of the block to select the service for which you want to add metrics.

Pictured below, there are several block settings that allow you to configure the block, the metrics you wish to enter and how the metric date should be determined. Please note that the image below is an Obsidian block.

1 Name

You probably won't need to change this, but if you want to customize the block's name you can do so here.

2 Schedule Category

This is where you'll identify the schedule category that has your service times.

3 Weeks Back

For this block, you don't need to scroll through a list of every service you've ever had. Still, it's likely you'll need to add metrics for services in the recent past. This setting lets you control how far back, in weeks, you can enter service metrics.

4 Weeks Ahead

Similar to the above setting, you can control how far ahead metrics can be entered for a service. A value of zero, as shown in the screenshot, won't let you select any services beyond the current week.

5 Default to Current Week

When enabled, this block will bypass the step to select a week from a list and will instead skip right to the entry page with the current week selected.

6 Metric Categories

This setting determines which metrics will be entered on the page. In this example, the weekly metrics of "Adult Attendance" and "Salvations" have been selected in the block's settings, allowing fields for those metrics to appear on the page for data entry.

7 Campuses

You can optionally limit this block to one or more campuses. If no campuses are selected, then metrics can be entered for any campus.

8 Insert 0 for Blank Items

When it comes to metrics, there can be a pretty big difference between a blank/empty value and an actual zero. If this setting is enabled, any blank values will automatically be replaced with a "0" by Rock when you save.

9 Remove Values When Deleted

If enabled, metrics that already exist will be deleted if you remove the number from the entry page. This would result in a blank value, so the metric will not be deleted if you've enabled the Insert 0 for Blank Items option above.

10 Metric Date Determined By

This setting determines what date to use when adding the metric. 'Sunday Date' will use the selected Sunday date from the page. 'Day from Schedule' will use the first day that's configured from the schedule selected above. When using 'Day from Schedule' remember that Sunday is the last day of the week.

11 Limit Campus Selection to Campus Team Membership

If you have Campus Teams set up then you can enable this setting to narrow down the list of campuses to only the ones where the person is part of the Campus Team.

12 Campus Type and Status

Selecting options here will limit the campuses available for entry according to their Type and Status. For instance, you might only want to show Physical campuses that are Open.

13 Filter Schedules by Campus

Enabling this will restrict the Schedules available to only those associated with the campus. This only applies if you have Campus Schedules configured.

14 Show Metric Category Subtotals

As pictured below, you can enable this to sum up metric values by category. Higher-level categories would provide a sum of the child categories beneath it.

15 Roll-up Category Depth

This setting determines how far up in the category tree you should go (1 = parent, 2 = grandparent, etc.) when entering metrics..

16 Include Duplicate Metrics in Category Subtotals

A single metric can be in more than one category. This setting determines if it should be counted more than once when it appears in multiple categories.

Below, you'll find an alternative view of the Weekly Metrics page, showcasing the activation of some of the optional block settings mentioned earlier. Specifically, the options related to the metric categories.

Calculating Metrics

Metric values can be added using the methods described above. However, metrics that use a Source Type of SQL, Data View or Lava can be automatically calculated based on a schedule you provide when editing or creating the metric. The calculations are performed when the Calculate Metrics job is run. As pictured below, this job runs once every 15 minutes to process any metrics that need to be calculated based on their schedule. If you have a SQL metric that takes a long time to process, you can adjust the Command Timeout job setting to allow the calculation to be completed.

Metrics can also be calculated on demand, rather than waiting for the Calculate Metrics job to calculate the metric based on its schedule. Simply click the button pictured below to calculate any metric that uses SQL, Data View or Lava as its Source Type. Manually calculating a metric in this way will not disrupt the schedule on which it normally calculates.

Anatomy of a Dashboard

1Theme

While dashboard blocks can be placed on any page in Rock, we do ship with a special theme designed for dashboards called Dashboard Stark. This a very basic starter theme for you to use as a starting point for creating your own. When you do create new dashboard themes, we highly recommend you prefix their name with Dashboard to help keep them grouped together in lists.

2Dashboard Widgets

The widgets are simply Rock blocks on the page. We discuss each type of block below in detail.

3Context Setter

While optional, a context setting on the page allows you to filter the metric values by their Series Partition. Many times, this is a campus selector or group selector.

Dashboard Blocks

Rock ships with several dashboard widget blocks. Each of these blocks is shown below.

Line Chart

This block displays a line chart for the selected metric. Options include:

Title	Description
Name	This is the block name. It is not displayed anywhere on the output of the block.
Title	The title that is displayed for the metric.
Subtitle	The subtitle for the metric.
Column Width	The number of Bootstrap columns the chart should use for its width. (A Bootstrap row, by default, has 12 columns.)
Chart Style	The chart style to use. These styles are defined under Admin Tools > Settings > Defined Types > Chart Styles.
Metric	The metric to use for the chart.
Partition Filter	Determines how the chart will get the series partition value. It can be either hard coded or determined from the page context.
Date Range	Determines which values are displayed on the graph.
Detail Page	This optional setting will determine which page will be loaded when the graph is clicked.

Pie Chart

This block displays a pie chart for a given metric. Options include:

Lava Dashboard Widget

This block renders the metric values using a Lava template. Options include:

See our Lava documentation for more information.