Understanding Program Criteria Types

The Partner Program Tiers module supports six distinct criterion types that enable comprehensive partner performance measurement across revenue achievement, sales activity, training completion, and custom qualitative requirements. Each criterion type integrates with specific Magentrix modules and data sources, providing flexible measurement capabilities that align with diverse business objectives and partner engagement strategies.

Understanding the unique characteristics, configuration requirements, and appropriate use cases for each criterion type enables administrators to design effective tier qualification frameworks that accurately measure partner performance and motivate strategic behaviors.

Requirements

To create and configure program criteria, users must be assigned a security role with one of the following permissions:

• Administrator System Role
• Users in Roles that have Additional Settings: Enable Partner Program Tiers Access

Criterion Type Overview

Partner Program Tiers provides six criterion types, each designed to measure specific aspects of partner performance:

1. Total Revenue - Measures cumulative opportunity revenue
2. Approved Deal Registrations - Tracks approved lead registrations
3. Closed Deals - Counts successfully closed opportunities
4. Number of Deals Registered - Measures deal registration volume
5. Certifications - Monitors training course completion
6. Custom - Enables manual verification of qualitative requirements

Total Revenue

Purpose and Measurement

The Total Revenue criterion type measures the cumulative monetary value of opportunities associated with a partner account. This criterion evaluates partner revenue contribution by summing currency field values from opportunities that meet specified filter conditions and fall within the partner's enrollment period.

Data Source and Integration

Primary Data Source: Opportunity records

Evaluation Logic: The system queries all opportunities associated with the partner account (using Primary Partner User's data access permissions), applies configured filters, checks that the Attainment Date falls within the enrollment period, and sums the values from the selected Rollup Field.

Required Configuration Fields

Rollup Field:

• Purpose: Specifies which currency field from the Opportunity object contains the revenue amount to be summed
• Field Type: Must be a currency field from the Opportunity entity
• Common Selections:
  • Amount (standard opportunity amount)
  • Annual Revenue
  • Total Contract Value
  • Recurring Revenue
  • Any custom currency field defined in your opportunity structure
• Configuration: Select from dropdown of all currency fields available on Opportunity

Attainment Date Field:

• Purpose: Determines when the opportunity revenue should be counted toward partner progress
• Field Type: Must be a date or date/time field from the Opportunity entity
• Common Selections:
  • Close Date (counts revenue when opportunity closes)
  • Created On (counts revenue when opportunity is created)
  • Stage Change Date (counts revenue when specific stage is reached)
  • Any custom date/time field that represents revenue recognition timing
• Configuration: Select from dropdown of all date/time fields available on Opportunity
• Enrollment Period Logic: Only opportunities where the Attainment Date falls between the partner's Enrollment Date and Expiration Date are counted

Filter Configuration

Filter Object: Opportunity fields

Purpose: Filters enable you to include only relevant opportunities in revenue calculations, excluding internal opportunities, test data, or non-qualifying business types.

Common Filter Examples:

Count Only Closed Won Opportunities:

• Field: Stage
• Operator: equals
• Value: Closed Won

Exclude Internal Opportunities:

• Field: Account Type
• Operator: not equals to
• Value: Internal

Include Only Direct Sales (Exclude Referrals):

• Field: Opportunity Type
• Operator: equals
• Value: Direct

Minimum Opportunity Size Threshold:

• Field: Amount
• Operator: greater or equal
• Value: 10000

Use Cases and Examples

Annual Partner Revenue Measurement:

• Rollup Field: Amount
• Attainment Date Field: Close Date
• Filter: Stage equals "Closed Won"
• Business Purpose: Measure total closed revenue to determine partner tier qualification based on sales performance

Quarterly Revenue Targets:

• Rollup Field: Amount
• Attainment Date Field: Close Date
• Filter Logic: "1 and 2" where (1) Stage equals "Closed Won" AND (2) Close Date within quarter
• Business Purpose: Track quarterly revenue achievement for time-based tier qualification

Recurring Revenue Measurement:

• Rollup Field: Annual Recurring Revenue (custom field)
• Attainment Date Field: Contract Start Date
• Filter: Opportunity Type equals "Renewal" or "New Subscription"
• Business Purpose: Measure subscription-based revenue contribution for SaaS partners

Best Practices

Attainment Date Selection: Choose the date that best represents when revenue should be recognized for tier qualification purposes. Close Date is most common, but Created On may be appropriate for pipeline-based programs.

Filter Specificity: Use precise filters to ensure accurate revenue counting. Test filters with known data sets to verify correct behavior before program activation.

Currency Consistency: Remember that in multi-currency environments, the system automatically converts all opportunity values to program currency during calculation.

Approved Deal Registrations

Purpose and Measurement

The Approved Deal Registrations criterion type tracks the number of lead registrations submitted by partners that have been approved by your organization. This criterion measures partner pipeline generation activity and deal registration engagement.

Data Source and Integration

Primary Data Source: Lead records

Evaluation Logic: The system queries all leads associated with the partner account (using Primary Partner User's data access permissions), applies configured filters (typically checking for approval status), verifies the Attainment Date falls within the enrollment period, and counts the qualifying lead records.

Required Configuration Fields

Attainment Date Field:

• Purpose: Determines when the lead registration should be counted toward partner progress
• Field Type: Must be a date or date/time field from the Lead entity
• Common Selections:
  • Created On (counts registration when lead is created)
  • Approval Date (counts registration when approved)
  • Status Change Date (counts registration when status changes to approved)
  • Any custom date/time field that represents registration timing
• Configuration: Select from dropdown of all date/time fields available on Lead
• Enrollment Period Logic: Only leads where the Attainment Date falls between the partner's Enrollment Date and Expiration Date are counted

Filter Configuration

Filter Object: Lead fields

Purpose: Filters enable you to count only approved registrations, exclude rejected or pending submissions, and focus on specific business types or product lines.

Common Filter Examples:

Count Only Approved Registrations:

• Field: Status
• Operator: equals
• Value: Approved

Exclude Rejected Registrations:

• Field: Status
• Operator: not equals to
• Value: Rejected

Specific Product Line Registrations:

• Field: Product Interest
• Operator: equals
• Value: Enterprise Solutions

Minimum Deal Size Threshold:

• Field: Estimated Value
• Operator: greater or equal
• Value: 50000

Use Cases and Examples

Approved Deal Registration Volume:

• Attainment Date Field: Approval Date
• Filter: Status equals "Approved"
• Business Purpose: Measure partner engagement in deal registration program and pipeline contribution

Qualified Pipeline Generation:

• Attainment Date Field: Created On
• Filter Logic: "1 and 2" where (1) Status equals "Approved" AND (2) Lead Score greater than 70
• Business Purpose: Count only high-quality registrations that meet qualification standards

Product-Specific Registration Activity:

• Attainment Date Field: Approval Date
• Filter Logic: "1 and 2" where (1) Status equals "Approved" AND (2) Product Category equals "Cloud Services"
• Business Purpose: Incentivize partner focus on strategic product lines

Best Practices

Filter for Approval Status: Always include a filter for approval status to ensure only approved registrations count toward tier qualification. Counting pending or rejected registrations inflates partner progress inaccurately.

Attainment Date Alignment: Choose whether to count registrations when submitted (Created On) or when approved (Approval Date). Approval Date is more common as it reflects your organization's validation of the registration quality.

Duplicate Prevention: If your deal registration process allows multiple submissions for the same opportunity, consider additional filter logic to prevent duplicate counting.

Closed Deals

Purpose and Measurement

The Closed Deals criterion type counts the number of opportunities that have been successfully closed and won. This criterion measures partner sales effectiveness and win rate contribution, focusing on deal volume rather than revenue amount.

Data Source and Integration

Primary Data Source: Opportunity records

Evaluation Logic: The system queries all opportunities associated with the partner account (using Primary Partner User's data access permissions), applies configured filters (typically checking for Closed Won stage), verifies the Attainment Date falls within the enrollment period, and counts the qualifying opportunity records.

Required Configuration Fields

Attainment Date Field:

• Purpose: Determines when the closed opportunity should be counted toward partner progress
• Field Type: Must be a date or date/time field from the Opportunity entity
• Common Selections:
  • Close Date (counts deal when opportunity closes)
  • Stage Change Date (counts deal when stage changes to Closed Won)
  • Contract Signed Date (counts deal when contract is executed)
  • Any custom date/time field that represents deal closure timing
• Configuration: Select from dropdown of all date/time fields available on Opportunity
• Enrollment Period Logic: Only opportunities where the Attainment Date falls between the partner's Enrollment Date and Expiration Date are counted

Filter Configuration

Filter Object: Opportunity fields

Purpose: Filters enable you to count only successfully closed opportunities, exclude lost deals, and focus on specific opportunity characteristics that align with program objectives.

Common Filter Examples:

Count Only Closed Won Opportunities:

• Field: Stage
• Operator: equals
• Value: Closed Won

Exclude Small Deals:

• Field: Amount
• Operator: greater or equal
• Value: 25000

Specific Business Type:

• Field: Opportunity Type
• Operator: equals
• Value: New Customer

Partner-Sourced Deals Only:

• Field: Lead Source
• Operator: equals
• Value: Partner Registration

Use Cases and Examples

Total Win Count:

• Attainment Date Field: Close Date
• Filter: Stage equals "Closed Won"
• Business Purpose: Measure partner sales productivity and deal closure capability

New Customer Acquisition:

• Attainment Date Field: Close Date
• Filter Logic: "1 and 2" where (1) Stage equals "Closed Won" AND (2) Account Type equals "New Customer"
• Business Purpose: Incentivize new customer acquisition over existing account expansion

Enterprise Deal Closures:

• Attainment Date Field: Close Date
• Filter Logic: "1 and 2" where (1) Stage equals "Closed Won" AND (2) Deal Size equals "Enterprise"
• Business Purpose: Recognize partners who successfully close complex, high-value opportunities

Best Practices

Stage Filter Requirement: Always filter for Closed Won stage (or equivalent) to ensure only successfully closed opportunities are counted, excluding lost, abandoned, or in-progress opportunities.

Deal Size Considerations: Consider whether all deal sizes should count equally. Small deals may require minimum thresholds to prevent inflation of closure counts with low-value transactions.

Attribution Clarity: Use filters to ensure counted opportunities properly reflect partner contribution (e.g., partner-sourced, partner-influenced) rather than counting all opportunities associated with partner accounts.

Number of Deals Registered

Purpose and Measurement

The Number of Deals Registered criterion type measures the volume of deal registrations submitted by partners, regardless of approval status. This criterion evaluates partner engagement with the deal registration program and pipeline development activity levels.

Data Source and Integration

Primary Data Source: Lead records

Evaluation Logic: The system queries all leads associated with the partner account (using Primary Partner User's data access permissions), applies configured filters, verifies the Attainment Date falls within the enrollment period, and counts the qualifying lead records.

Required Configuration Fields

Attainment Date Field:

• Purpose: Determines when the deal registration should be counted toward partner progress
• Field Type: Must be a date or date/time field from the Lead entity
• Common Selections:
  • Created On (counts registration when lead is submitted)
  • Registration Date (counts registration when formally registered)
  • Status Change Date (counts registration based on status transitions)
  • Any custom date/time field that represents registration timing
• Configuration: Select from dropdown of all date/time fields available on Lead
• Enrollment Period Logic: Only leads where the Attainment Date falls between the partner's Enrollment Date and Expiration Date are counted

Filter Configuration

Filter Object: Lead fields

Purpose: Filters enable you to count all registrations or focus on specific registration types, statuses, or characteristics that align with program objectives.

Common Filter Examples:

Count All Registrations (No Status Filter):

• No filter required if counting all submissions
• Alternative: Field: Status, Operator: not equals to, Value: Deleted/Invalid

Count Only Pending and Approved Registrations:

• Field: Status
• Operator: contains
• Value: Pending, Approved

Specific Product Registrations:

• Field: Product Category
• Operator: equals
• Value: Enterprise Software

Exclude Test Registrations:

• Field: Lead Type
• Operator: not equals to
• Value: Test

Use Cases and Examples

Total Registration Activity:

• Attainment Date Field: Created On
• Filter: Status not equals "Deleted"
• Business Purpose: Measure overall partner engagement with deal registration program

Pipeline Development Activity:

• Attainment Date Field: Registration Date
• Filter: No filter (count all registrations)
• Business Purpose: Track partner pipeline generation activity volume regardless of approval

Qualified Registration Submissions:

• Attainment Date Field: Created On
• Filter: Lead Score greater than 50
• Business Purpose: Count registrations that meet minimum qualification standards

Use Case Distinction

Approved Deal Registrations vs. Number of Deals Registered:

Use Approved Deal Registrations when:

• You want to incentivize quality over quantity
• Partner should only receive credit for approved registrations
• You want to encourage submission of high-quality, well-qualified opportunities

Use Number of Deals Registered when:

• You want to encourage high-volume registration activity
• You want to measure partner engagement levels regardless of approval outcomes
• You want to track pipeline development efforts before qualification

Best Practices

Status Filtering Decisions: Decide whether to count all registrations or exclude specific statuses (rejected, deleted, invalid). This decision impacts whether partners are incentivized for volume or quality.

Duplicate Prevention: If partners can submit multiple registrations for the same opportunity, consider filter logic or data management procedures to prevent duplicate counting.

Quality Considerations: If using this criterion without approval filtering, consider pairing it with other quality-focused criteria to maintain balanced incentives.

Certifications

Purpose and Measurement

The Certifications criterion type monitors partner completion of designated training courses. This criterion measures partner investment in capability development, product knowledge, and sales/technical skill advancement through formal training programs.

Data Source and Integration

Primary Data Source: Course Assignment records

Evaluation Logic: The system queries all course assignments associated with the partner account users (using Primary Partner User's data access permissions), checks for assignments of the specified training course, applies configured filters (typically checking for completion status), and counts the qualifying course assignment records.

Required Configuration Fields

Training Course:

• Purpose: Specifies which training course must be completed to satisfy the criterion
• Field Type: Lookup to Training Course records
• Configuration: Select the specific course from the lookup field
• Note: Each Certifications criterion can track only one training course. Create multiple Certifications criteria to track multiple required courses.

Filter Configuration

Filter Object: Course Assignment fields

Purpose: Filters enable you to count only completed courses, exclude in-progress or failed attempts, and focus on specific completion characteristics.

Common Filter Examples:

Count Only Completed Courses:

• Field: Status
• Operator: equals
• Value: Completed

Count Passed Certifications Only:

• Field: Result
• Operator: equals
• Value: Passed

Exclude Expired Certifications:

• Field: Expiration Date
• Operator: greater than
• Value: Today

Minimum Score Requirement:

• Field: Score
• Operator: greater or equal
• Value: 80

Use Cases and Examples

Sales Certification Requirement:

• Training Course: Product Sales Fundamentals
• Filter: Status equals "Completed"
• Business Purpose: Ensure partners complete foundational sales training before advancing to higher tiers

Technical Certification Count:

• Training Course: Advanced Technical Certification
• Filter Logic: "1 and 2" where (1) Status equals "Completed" AND (2) Score greater or equal 80
• Business Purpose: Track technical proficiency through certification achievement with minimum passing scores

Current Certification Validation:

• Training Course: Annual Certification Renewal
• Filter Logic: "1 and 2" where (1) Status equals "Completed" AND (2) Expiration Date greater than Today
• Business Purpose: Ensure certifications remain current and not expired

Multiple Certifications Tracking

To track multiple certification requirements:

1. Create separate Certifications criteria for each required course
2. Set tier-specific thresholds for each criterion
3. Partners must complete all specified courses to meet tier requirements

Example:

• Criterion 1: Sales Fundamentals Certification (Launch: 1, Build: 1, Scale: 1, Elevate: 1)
• Criterion 2: Technical Fundamentals Certification (Launch: -, Build: 1, Scale: 1, Elevate: 1)
• Criterion 3: Advanced Technical Certification (Launch: -, Build: -, Scale: 1, Elevate: 2)

Best Practices

Completion Status Filtering: Always filter for completion status to ensure only finished courses count toward tier qualification. Exclude in-progress, abandoned, or failed attempts.

Certification Currency: For certifications with expiration dates, include expiration date filters to ensure only current, valid certifications are counted.

Course Naming Clarity: Use clear, specific training course names that clearly communicate certification requirements to partners.

Progressive Requirements: Structure certification requirements to increase at higher tiers, encouraging continuous learning and capability development.

Custom

Purpose and Measurement

The Custom criterion type enables manual verification of qualitative requirements that cannot be automatically measured through system data. This criterion provides flexibility to include strategic partnership requirements, business planning activities, executive engagement, or other qualitative achievements in tier qualification frameworks.

Data Source and Integration

Primary Data Source: Manual administrator verification

Evaluation Logic: Administrators manually verify that partners have completed the custom requirement and manually update partner tier placement when custom criteria are satisfied. Custom criteria do not automatically calculate or update based on system data.

Required Configuration Fields

Unit of Measure:

• Purpose: Specifies how the custom criterion is measured or evaluated
• Field Type: Picklist selection
• Available Options:
  • Revenue (for custom revenue-based requirements)
  • Percent (for percentage-based requirements)
  • Other measurement types defined in your system
• Configuration: Select the appropriate measurement type from the dropdown
• Note: Unit of Measure selection provides context but does not affect automatic calculation, as Custom criteria are manually verified

Filter Configuration

Filter Object: None

Custom criteria do not support filter configuration because they rely on manual verification rather than automated data queries.

Use Cases and Examples

Joint Business Plan Submission:

• Unit of Measure: Revenue (representing planned revenue in business plan)
• Threshold: Yes/No at each tier level
• Business Purpose: Require strategic business planning collaboration as partners advance to higher tiers
• Verification: Administrator reviews submitted business plan and manually confirms completion

Executive Sponsor Assignment:

• Unit of Measure: Percent (completion indicator)
• Threshold: Yes/No at elite tiers
• Business Purpose: Ensure top-tier partners receive executive engagement and strategic support
• Verification: Administrator confirms executive sponsor has been assigned and engaged

Partnership Agreement Execution:

• Unit of Measure: Revenue (representing contract value)
• Threshold: Yes/No for advanced tiers
• Business Purpose: Formalize partnership relationship through legal agreement at higher tier levels
• Verification: Administrator confirms signed partnership agreement is on file

Annual Partner Review Meeting:

• Unit of Measure: Percent (completion indicator)
• Threshold: Yes/No annually
• Business Purpose: Require regular strategic review meetings for tier maintenance
• Verification: Administrator confirms meeting occurred and documents discussion

Webinar or Event Hosting:

• Unit of Measure: Percent (completion indicator)
• Threshold: Number of events hosted per tier
• Business Purpose: Encourage partner marketing engagement through event participation
• Verification: Administrator tracks hosted events and manually updates progress

Configuration and Threshold Setting

When configuring Custom criteria thresholds:

For Yes/No Requirements:

• Set threshold values as "Yes" or "No" in tier columns
• "No" indicates requirement does not apply at that tier
• "Yes" indicates requirement must be manually verified at that tier

For Quantitative Requirements:

• Enter numeric values representing quantity expected (e.g., number of events, number of joint projects)
• Administrators manually verify and update progress toward these numeric thresholds

Manual Verification Process

1. Partner completes the qualitative requirement
2. Partner notifies administrator or administrator identifies completion through regular review
3. Administrator verifies completion through documentation review, meeting confirmation, or other validation
4. Administrator navigates to partner enrollment and manually updates tier placement if all criteria (including custom) are satisfied
5. Administrator documents verification for audit purposes

Best Practices

Clear Definition: Document custom criteria requirements extensively so partners understand exactly what must be accomplished and what verification evidence is required.

Verification Standards: Establish clear internal standards for what constitutes satisfactory completion of custom requirements to ensure consistency across partner evaluations.

Documentation Requirements: Specify what documentation partners must provide (e.g., signed agreement copies, business plan documents, event attendance records) to support verification.

Communication: Communicate clearly with partners about custom requirements, verification processes, and expected timelines for administrator review and confirmation.

Audit Trail: Maintain documentation of custom requirement completion and verification for program audit purposes and historical reference.

Progressive Complexity: Use custom criteria sparingly at entry-level tiers, increasing qualitative requirements at higher tiers where strategic partnership depth justifies manual verification overhead.

Criterion Configuration Summary

Configuration Requirements by Type

Data Source by Criterion Type

Best Practices Across All Criterion Types

Attainment Date Field Selection

Consistency: Use the same attainment date field consistently across similar criteria within a program to ensure fair measurement and partner understanding.

Business Logic Alignment: Choose attainment date fields that align with when you want to recognize partner achievement (e.g., Close Date for when deals actually close, Created On for when pipeline is generated).

Enrollment Period Impact: Remember that attainment date fields determine which activities count within each partner's enrollment period, so selection significantly impacts progress calculation.

Filter Logic Best Practices

Test Thoroughly: Test filter logic with known data sets before program activation to verify calculations match expectations and include intended records.

Document Rationale: Maintain internal documentation of filter logic decisions and business rationale to support consistent program management and troubleshooting.

Simple When Possible: Use simple, clear filter logic when possible. Complex multi-condition filters increase configuration complexity and troubleshooting difficulty.

Common Patterns: Develop standard filter patterns for common requirements (e.g., "Closed Won only", "Approved registrations only") that can be reused across programs.

Criterion Combination Strategies

Balanced Measurement: Combine quantitative criteria (revenue, deal counts) with qualitative criteria (certifications, custom) to encourage well-rounded partner development.

Progressive Complexity: Start with fewer, simpler criteria at entry-level tiers and add more sophisticated requirements at higher tiers to reflect increasing partnership maturity.

Complementary Metrics: Choose criteria that measure different aspects of partnership success rather than multiple variations of the same metric.

Troubleshooting Common Issues

Criterion Not Calculating:

• Verify Primary Partner User has appropriate data access permissions
• Check filter logic for overly restrictive conditions
• Confirm activities occurred within enrollment period based on Attainment Date Field
• Review field selections for accuracy (correct field names, correct object)

Unexpected Results:

• Test filter logic with manual queries to verify expected behavior
• Check for data quality issues (missing values, incorrect stage names, etc.)
• Verify Attainment Date Field values fall within enrollment dates
• Review Primary Partner User access permissions for completeness

Custom Criteria Not Updating:

• Remember that Custom criteria require manual administrator verification
• Check that administrators understand manual update process
• Verify documentation requirements are clear to partners and administrators

Jump to Partner Program Tiers Checklist

<< Creating and Managing Partner Programs | Defining and Assigning Program Benefits >>