Work prioritization example

  • Release version: Zurich
  • Updated April 1, 2026
  • 4 minutes to read
  • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Work Prioritization Example

    This example demonstrates how a manufacturing organization configures work prioritization rules in the ServiceNow SPO application for three record types: purchase requisitions, sourcing requests, and procurement cases. The aim is to prioritize work items based on business-relevant criteria to ensure critical tasks receive faster attention and appropriate oversight.

    Show full answer Show less

    Prioritization Rules Configuration

    • Purchase Requisitions: Priority is assigned based on the total value of each purchase line item. Higher value lines are treated with higher urgency:
      • Critical: $100,000 or more
      • High: $50,000 to $99,999
      • Moderate: $25,000 to $49,999
      • Low: $24,999 or less
    • Sourcing Requests: Priority depends on the organizational seniority of the business owner sponsoring the request:
      • Critical: CFO or CEO
      • High: IC4-level and above
      • Moderate: Manager level
      • Low: IC1 to IC3 levels
    • Procurement Cases: Priority is set according to the type of modification requested, reflecting associated organizational risk:
      • High: Supplier change or Contract amendment
      • Moderate: Price change
      • Low: Catalog update or Description change

    How Prioritization Works in Practice

    • Mixed Line Values in Purchase Requisitions: When a requisition includes multiple lines with varying values, the system evaluates each line's priority and assigns the overall purchase requisition the highest priority found among its lines. For example, a requisition with two low-value lines and one high-value line will receive a high priority to ensure timely handling.
    • Sourcing Requests by Business Owner: The priority changes based on who sponsors the request, reflecting the organizational importance of the business owner’s role. A request sponsored by a senior leader like a CFO is critical, while one sponsored by a manager is moderate.
    • Procurement Cases with Mixed Modifications: For cases with multiple modification types, the highest priority among all lines determines the case’s overall priority. This ensures that strategically significant changes, such as supplier changes, receive prompt attention even if other updates are routine.
    • Handling Records Without Matching Rules: Records evaluated before prioritization rules are configured receive a default Planning priority and appear at the bottom of the work queue. Once rules are added, these records are re-evaluated automatically upon creation or update to assign the appropriate priority.

    Benefits for ServiceNow Customers

    By configuring work prioritization rules tailored to specific record types and business criteria, organizations gain consistent, automated prioritization that helps specialists focus on the most critical tasks first. This approach improves responsiveness, resource allocation, and risk management across procurement and sourcing processes. Additionally, the system’s ability to handle incomplete rule configurations ensures continuity and gradual adoption without disruption.

    This example shows how an organization might configure work prioritization rules for all three record types, and what happens when records are evaluated against those rules.

    A manufacturing organization has deployed the SPO application and is configuring work prioritization for the first time. Their procurement team has agreed on three different criteria, one per record type, that reflect the factors most relevant to their business.

    Example configuration

    For purchase requisitions, the team prioritizes based on the total value of each line item. Larger-spend lines require faster turnaround and tighter oversight.

    Table 1. Priority defaulting for purchase requisitions — example rules
    Rule Condition Priority assigned
    1 Purchase line total amount is $100,000 or more Critical
    2 Purchase line total amount is between $50,000 and $99,999 High
    3 Purchase line total amount is between $25,000 and $49,999 Moderate
    4 Purchase line total amount is $24,999 or less Low

    For sourcing requests, the team prioritizes based on the organizational seniority of the business owner. Requests sponsored by senior leaders require faster response.

    Table 2. Priority defaulting for sourcing requests — example rules
    Rule Condition Priority assigned
    1 Business owner job code is CFO or CEO Critical
    2 Business owner job code is IC4 or above High
    3 Business owner job code is a Manager level Moderate
    4 Business owner job code is IC1, IC2, or IC3 Low

    For procurement cases, the team prioritizes based on the type of modification being requested. Supplier changes and contract amendments carry higher organizational risk than routine catalog updates.

    Table 3. Priority defaulting for procurement cases — example rules
    Rule Condition Priority assigned
    1 Case line modification type is Supplier change or Contract amendment High
    2 Case line modification type is Price change Moderate
    3 Case line modification type is Catalog update or Description change Low

    Purchase requisition with mixed line values

    A department manager submits a purchase requisition for three items: office furniture ($12,000), a desktop workstation ($8,500), and a conference room display system ($67,000).

    When the requisition is saved, the system evaluates each line against the decision table. The furniture line ($12,000) matches Rule 4 and returns Low. The workstation line ($8,500) also matches Rule 4 and returns Low. The display system line ($67,000) matches Rule 2 — its amount falls between $50,000 and $99,999 — and returns High.

    The system selects the most urgent result across all three lines: High. The priority field on the purchase requisition is updated to High.

    When the requisition appears in the specialist's queue, it is flagged as High — driven by the single large-value line, even though the other two lines were routine in scale. The specialist knows to examine the requisition promptly and will find the $67,000 display system line when they open it.

    Sourcing request based on business owner seniority

    A sourcing event is created to evaluate suppliers for a new category of raw materials. The business owner on the request holds a job code that corresponds to an IC4-level role.

    When the sourcing request is saved, the system evaluates the business owner's job code against the decision table. The IC4 job code matches Rule 2 and the sourcing request receives High priority.

    If the same sourcing event had been initiated by a manager-level business owner, the request would have received Moderate priority instead. The same sourcing event, sponsored by a different person, lands differently in the queue — reflecting the organizational importance of who is sponsoring the work.

    Procurement case with mixed modification types

    A specialist creates a procurement case to handle updates across three items. Two of the case lines are routine description changes. The third documents a supplier change — a strategic decision with contract implications.

    When the case is saved and its lines are evaluated, the two description change lines match Rule 3 and return Low. The supplier change line matches Rule 1 and returns High.

    The system selects High as the priority for the parent case. When a manager reviews the team's open work queue, this case appears above the routine catalog-update cases — signaling that it contains at least one strategically significant line.

    Record with no matching rule

    Before this organization finishes configuring the procurement case decision table, a procurement case is created. The table has no rules yet. The system evaluates the decision table, finds no matching rule, and the case receives Planning priority — the system default. It appears at the bottom of the work queue.

    After the rules are configured in the table, the system re-evaluates the case the next time it is created or updated. If a matching rule is found, the priority updates accordingly.

    This means work prioritization does not require all rules to be in place before the feature is active. Records created before rules are configured accumulate at Planning priority and are re-evaluated naturally as they are updated.