Denying a request ends the approval process immediately. The request is marked Denied, the submitter is notified, and the request does not advance to any further approval levels.

When to Deny

Deny a request when the discount being requested is outside acceptable parameters, the deal details are incomplete or inaccurate, or the request type doesn’t match the situation. If the request just needs adjustments — different pricing, a missing product, a corrected quantity — it’s better to communicate that to the submitter so they can create a new request with the right details.

How to Deny a Request

1. Open the request from your Pending queue.
2. Review the request details and line items.
3. Click Deny in the action bar.
4. In the dialog that appears, enter a reason for denial. This field is required — the submitter will see your reason in the approval history and in their notification email, so be clear and specific.
5. Click Confirm Denial.

The request status changes to Denied immediately.

What the Submitter Sees

After a denial, the submitter receives an email notification with:

• The name of the request that was denied
• The level at which it was denied
• The name of the approver who denied it
• The reason you provided

On the request detail page, the denial reason appears in the approval history log. The submitter cannot edit the denied request, but they can create a new one with revised terms.

What You Can Do After Denying

Once a request is denied:

• It moves to the Denied tab on the Requests list
• It can be exported as CSV or archived, but not re-submitted or edited
• Your denial is permanently recorded in the request’s approval history

If a denial was made in error, contact your Administrator. Administrators cannot reverse a denial directly, but they can archive the request and allow the submitter to create a replacement.

Denial vs. Requesting Changes

DiscountFlow doesn’t have a “request changes” or “return to submitter” action. If you need the submitter to revise something before you can approve, deny the request with a clear explanation of what needs to change, and ask the submitter to create a new request. This approach keeps the audit trail clean — every request has a definitive outcome, and the revised pricing is documented in its own record.