Skip to main content

​
Overview

Metric policies automate metric collection by defining which metrics run on which calls. Instead of manually triggering metric collection, policies evaluate incoming calls against conditions and automatically collect the specified metrics when conditions match. The easiest way to create and manage policies is directly from the Roark dashboard: Metric Policies For programmatic access, policies are also fully supported via the Node.js SDK. The rest of this page covers the API approach.

​
How Policies Work

A metric policy consists of:
  1. Conditions (optional) — Rules that determine which calls the policy applies to
  2. Metrics — The metric definitions to collect when conditions are met
When a call is ingested, Roark evaluates all active policies. If a call matches a policy’s conditions (or if the policy has no conditions), the associated metrics are automatically collected.
A policy with no conditions applies to all calls in the project.

​
Creating a Policy

const policy = await client.metricPolicy.create({
  name: 'Production Agent Quality Checks',
  status: 'ACTIVE',
  conditions: [
    {
      conditions: [
        {
          conditionType: 'AGENT',
          conditionKey: 'your-agent-id',
        },
      ],
    },
  ],
  metrics: [
    { id: 'metric-definition-uuid-1' },
    { id: 'metric-definition-uuid-2' },
  ],
})
Parameters:
FieldTypeRequiredDescription
namestringYesDescriptive name for the policy
statusstringNoACTIVE (default) or INACTIVE
conditionsarrayNoCondition groups (omit to match all calls)
metricsarrayYesMetric definitions to collect (minimum 1)

​
Condition Types

Conditions determine which calls trigger the policy. Each condition group is an array of conditions that are evaluated together.
TypeDescriptionconditionKeyconditionOperatorconditionValue
AGENTMatch calls from a specific agentAgent ID——
CALL_SOURCEMatch calls from a specific sourceSource name (e.g., VAPI, RETELL)——
CALL_PROPERTYMatch on a call propertyProperty nameEQUALS, CONTAINS, STARTS_WITH, NOT_EQUALS, GREATER_THAN, LESS_THANValue to match
Example: Policy for VAPI calls only 
const policy = await client.metricPolicy.create({
  name: 'VAPI Call Metrics',
  conditions: [
    {
      conditions: [
        {
          conditionType: 'CALL_SOURCE',
          conditionKey: 'VAPI',
        },
      ],
    },
  ],
  metrics: [{ id: 'metric-definition-uuid' }],
})

​
Managing Policies

​
List Policies

const policies = await client.metricPolicy.list()

// With filters
const activePolicies = await client.metricPolicy.list({
  status: 'ACTIVE',
  limit: 50,
})
ParameterTypeDescription
limitnumberMax results (1-50, default: 20)
afterstringCursor for pagination
statusstringFilter by ACTIVE or INACTIVE

​
Get a Policy

const policy = await client.metricPolicy.getByID('policy-id')

​
Update a Policy

const updated = await client.metricPolicy.update('policy-id', {
  name: 'Updated Policy Name',
  status: 'INACTIVE',
})
All fields are optional. Pass an empty conditions array to remove all conditions.

​
Delete a Policy

const result = await client.metricPolicy.delete('policy-id')
System policies cannot be modified or deleted.

​
Adding Thresholds

When selecting metrics for a policy, you can optionally configure thresholds to turn raw metric values into pass/fail outcomes. For example, set Customer Satisfaction >= 7 to automatically flag calls that fall below your standard. Thresholds are configured inline when adding metrics to a policy — select a metric, click the threshold option, and choose an operator and value.

Thresholds Guide

Learn about operators, aggregation modes, and participant role filtering

​
System vs User Policies

System PoliciesUser Policies
Created byRoark automaticallyYou via API or dashboard
EditableNoYes
DeletableNoYes
Type fieldSYSTEMUSER
System policies are auto-created to ensure core metrics are always collected. They appear in the list endpoint with type: "SYSTEM".

​
Best Practices

Create a policy with no conditions to collect key metrics on all calls, then add targeted policies with conditions for specific use cases.
If you only need certain metrics for specific agents or sources, use conditions to avoid unnecessary processing.
Use descriptive names that indicate what the policy targets and what it measures (e.g., “Sales Agent - Conversion Metrics”).
Set a policy to INACTIVE instead of deleting it if you might need it again later.

​
What’s Next

Metrics

Learn about metric types, scopes, and how to create custom metrics

Metric Collection Jobs

Run metrics on demand for specific calls