---
sourceDocument: Yokohama Finance and Supply Chain
sourceDocumentLink: https://www.servicenow.com/docs/r/yokohama/source-to-pay-operations

 Release :

    - yokohama

ft:locale :

    - en-US

ft:publication_title :

    - Yokohama Finance and Supply Chain

ft:clusterId :

    - stpop

bundleId :

    - stpop

workflow :

    - Employee


---

# Approvals reassessment

# Approvals reassessment {#ariaid-title1}

* Release version: Yokohama
* 
* Updated January 30, 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read

Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) 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 Approvals Reassessment

This content explains the conditions and mechanisms for approvals reassessment in purchase automation within ServiceNow's Yokohama release.
It addresses how revisions or merges in purchase orders or requisitions affect approval workflows, the handling of approval due dates, and management of breached approvals.
Show full answer Show less  

## Key Features

* **Resend Approvals for Reassessment Property:** Controlled by the `snshop.approval.reassessment.resend` property, it determines if an approval needs reassessment following a revision or merge. This applies only if the same approval rule is triggered; new rules generate new approval plans.
* **Revision Constraints:** Reducing funds below already shipped or delivered amounts is disallowed. Revisions on rejected lines are not permitted, so reassessment does not apply in those cases.
* **Approval Amount Calculation:** When reassessing, the approval amount includes the original line amount plus any increase in funds. For example, increasing a $1000 line to $1500 results in reassessment at $1500.
* **Handling of In-Progress Approval Plans:** If the resend property is set to Yes and a revision or merge happens before approval completion, the existing plan is marked "No longer required" and a new plan is created. If set to No, the existing plan is reused.
* **Approval Restrictions:** Rejection of fully received lines during reassessment is not allowed. In ShoppingHub, these lines appear under the Approved tab.
* **Approval Due Date Population:** New approval records in Requested state have due dates calculated using two properties:
  * `snshop.pr.approval.duration`: Defines the approval duration in hours (default 9 hours).
  * `snshop.pr.approval.duration.schedule`: Defines the schedule type for duration (default 8-5 weekdays excluding holidays).
  Parallel approvals share the same due date; sequential approvals calculate due dates in sequence as each approver completes their task.
* **Breached Approval Review Task Creation:** A scheduled job runs daily to detect breached approval due dates and automatically creates purchasing tasks assigned to the purchase requisition owner. Sequential approvals generate tasks per overdue approver, while parallel approvals generate a single task with all breached approvers listed.
* **Task Due Dates and SLA Handling:** The due date of breach tasks matches the breach time on the SLA instance. Tasks and SLAs are not created or are deleted if approvals are canceled or no longer required.

## Practical Impact for ServiceNow Customers

ServiceNow customers managing purchase approvals benefit from automated reassessment workflows that respond dynamically to revisions, maintaining compliance with approval rules while preventing unauthorized reductions or changes on rejected or fully received lines.

The configurable properties allow tailoring approval reassessment behavior to organizational needs, balancing approval process continuity versus restarting approval plans after changes.

Automated due date management and breach detection ensure timely approvals, with built-in alerts and tasks to drive accountability and reduce approval delays.  
Review the conditions for approvals reassessment and their impact on purchase
automation.

## Resend approvals for reassessment property {#approvals-reassessment__section_yd5_krl_ynb}

The sn_shop.approval.reassessment.resend purchasing property determines if an approval
needs to be reassessed as a result of a revision or a merge. The revision could be that of a
purchase order or a purchase requisition. This property is only applicable if the same
approval rule is triggered. If a new rule is triggered, this property is not applicable and
a new approval plan is generated.

For information on approval rule groups and sequencing, and how these impact the property,
see [Approval rule grouping and sequencing](https://www.servicenow.com/docs/Bqj8BU5~pWkDrlXGx9P6gA "As a Procurement Administrator, you can associate approval rules with approval groups and define the sequence to determine when these rules should be triggered. With this association, a set of approval rules within a rule group is triggered in sequence, instead of all of them being evaluated simultaneously.").

A reduction in funds revision is not allowed if the amount is below what has already been
shipped or delivered. Revisions are not allowed on rejected lines, and therefore
reassessment of approvals is not applicable.

For information on approval rules, see [Approval rule types](https://www.servicenow.com/docs/OlqlI8nEsJdoDP3GplyXig "Approval rule types determine the methods by which approvals are created during the purchase requisition process.") and [Create an approval rule](https://www.servicenow.com/docs/2YRPq54ZYcwOrXLLK2jJsA "Approve a purchase requisition, purchase order, sourcing request, or invoice, by defining an approval strategy and creating approval rules. This is a one-place configuration that can drive any kind of approval process that your organization may need.").

When an approval reassessment is sent to approvers, the approval amount to be considered
must include the revised line's original amount and the increase in funds. For example, if
the original line amount is $1000 and an increase in funds revision results in the line
amount to be $1500, the amount to be considered for reassessment and approval is $1500.

When the resend approvals for assessment property is set to Yes, if there is an existing
approval plan record that is in progress, and a revision or merge occurs before the plan is
completed, its status is updated to No longer required, and a new plan is created. If the
property is set to No, and if the existing approval plan is in progress, it is reused.

During an approval reassessment, rejection of a fully received line is not allowed. In
ShoppingHub, the fully received line is displayed under the Approved
tab.

## Population of due date on approvals {#approvals-reassessment__section_xjm_wxk_ynb}

When a new approval record is generated and the state of the approval record is Requested, the due date for the record is calculated and populated using the following properties:

* sn_shop.pr.approval.duration: Duration, in hours, allocated for an approver to complete the approval request. By default, it is set to 9 hours.
* sn_shop.pr.approval.duration.schedule: The type of schedule associated to the approval duration. By default, it is set to 8-5 weekdays, excluding holidays.  
  Note:  
  The sys_id of the schedule is used as the value for this property.
{#approvals-reassessment__ul_ojg_y2l_ynb}

Parallel approval records have the same due date. For sequential approvals, the first
approver's due date is populated based on the property value defined, the second approver's
due date is calculated after the first approval is complete, and so on.

## Creation of breached approvals review task {#approvals-reassessment__section_vwb_m2l_ynb}

If a due date for an approval is breached, a new task is automatically created using the
\[PSM\] Approval Due Date Breached scheduled job, which runs once a day. This task is a
purchasing task, with subtype Approval, and is assigned to the same person to whom the
purchase requisition is assigned.

For sequential approval, this purchasing task is created for each approver record that is
overdue. For parallel approvals, a single task is created with a related list displaying all
the relevant approver records that have breached.

The due date of this task is populated with the breach time on the SLA instance record
associated to the SLA definition for the breached approvals review.

For approvals that are no longer required or are canceled, the breached approvals review
task creation is not triggered. Breached approvals review SLAs are deleted as they are no
longer required.

