Configure the Measurement Framework
Learning Objectives
After completing this unit, you’ll be able to:
- Identify the org, permissions, and data prerequisites that activity plan measurement depends on.
- Explain how Provider Activity Measure Types define which field activities count toward a goal.
- Determine when product-based tracking fits a commercial strategy.
- Diagnose configuration errors that distort scheduled and completed progress metrics.
Start with the Foundation
In the previous unit, you saw the data model behind activity plans and the business case for putting one in place. So far, that's all conceptual. You haven't turned on a setting, defined a rule, or created a plan.
Activity plans measure field work by reading activity records that are already in your org. The numbers are only as trustworthy as the setup behind them. Your job as an administrator is to confirm that the right users can configure and view plans, account and activity data is clean, and you've defined what counts as a qualifying interaction. You handle this setup once, and every plan you build later relies on it. It's the groundwork that helps Cumulus measure the launch of Immunexis, a new therapy for autoimmune disorders, before a single target exists.
This unit covers everything that comes before you create a specific plan. You confirm the user, permission, and data prerequisites that measurement depends on. Then you turn on the org-wide settings that control what field teams see and whether tracking follows individual products. Finally, you build the reusable measure types that decide which field activities count.
Prepare the Org for Reliable Measurement
Before you configure the feature, confirm your org is ready. Assign the applicable permission sets to admins, reps, and managers, clone and assign the right user profiles, and grant each role the field permissions it needs. Then confirm the data prerequisites that measurement depends on:
-
Territory structure: Assign reps and managers to their territories, with each manager in the parent territory of their reps.
-
Account specialties: Associate each target HCP account with an active, primary healthcare specialty record.
-
Picklist alignments: Confirm that the activity objects you measure, such as the standard Visit object, include picklist values for every channel your strategy tracks.
-
Active trigger handlers: Confirm the activity plan trigger handlers are active. A trigger handler is the behind-the-scenes automation that runs whenever a record is created or updated, and for activity plans, it keeps plan and territory records in sync as you build and adjust them.
For the full checklist, see Get Your Org Ready for Activity Plans.
With these configurations in place, you open the Admin Console to set up what your field teams see.
Turn On Account List Filters
Two settings put activity plan targets on your field teams' standard account lists: Show activity plans in filters and Show weighted activity plans in filters. You apply them as the org default for all users, or scope them to a specific profile when only certain teams work from plans, such as your field reps and managers.
From the App Launcher, open the Admin Console, choose Activity Plan, and open Activity Plan Settings. Under Table View Settings, select the two filter settings and save your changes.
With the settings on, the standard Accounts page shows list view filters for standard activity plans and weighted activity plans. Reps use those filters to separate their priority targets from the rest of their accounts. Scoping to a profile keeps those filters off the lists of users who never run plans.
Decide Whether to Track Progress by Product
Some commercial strategies focus only on overall account coverage, where every visit counts the same. A product launch is different. Leadership wants to know which therapy a rep discussed, because a rep can reach a target of 20 visits and still spend little of that time covering the launch product.
Product-based calculations address this gap. From the Admin Console, open Activity Plan Configuration and select Use product-based calculations under General Settings.
With this setting on, your tracking charts report progress by product instead of by raw visit count. The Cumulus launch needs exactly that. Its administrator turns on product-based calculations to track engagement tied to its launch product, Immunexis, rather than overall visit volume.
Choose this setting early. If you change it after targets and product records exist, you must redo that configuration work.
Define Which Activities Count
Now you create the rule that defines which field activities count: a Provider Activity Measure Type. The data model from the previous unit defines the objects and how they relate, but it doesn't say which records qualify as a tracked interaction. A measure type supplies that definition.
A measure type does three things. First, it identifies which records to count, by defining an activity object, the field that holds the channel, and the value that qualifies an interaction. Then it connects each qualifying record to an account, a territory, and a date, so the activity counts toward the right goal, team, and planning cycle. Finally, it separates scheduled work from completed work by sorting your status values into those two groups. That split is what later distinguishes a rep's upcoming pipeline from their finished attainment.
Cumulus tracks three channels separately, so its administrator creates one measure type each for In-Person, WhatsApp, and SMS. The records are identical except for the channel value. Here is the completed WhatsApp record.
Because each channel has its own measure type, Cumulus can give each one a different target and weight when it builds account goals in the next unit.
Validate Rules Before the Plan Depends on Them
The calculation engine does what your measure types tell it, so a small setup mistake can quietly skew the numbers. Check these three things before any plan goes live.
-
Picklist mismatch: You enter one channel in the measure type, but the Visit picklist uses another channel. No records match, and the metric stays empty.
-
Unmapped completed status: You leave the Completed status out of the status mapping, so finished visits never count and attainment stays at zero.
-
Wrong date field: You point the date field at the record's creation date instead of the planned start time, so activities fall into the wrong planning cycle.
Checking these fields, picklist values, and statuses in your test environments ensures that your measurement data remains fully accurate after your campaign goes live.
What’s Next?
You've confirmed your prerequisites, turned on the org-wide settings, and built the measure types that define which field activities count. The foundation is in place.
In the next unit, you put it to work. You create an activity plan, set its review thresholds, connect it to a territory, and break account goals into weighted, product-specific measures.