Source-to-Pay on ServiceNow, Part 4: Supplier Document Expiry, Renewal and Notifications

[sachinbhasin11]

Supplier Document Management in SLO: Expiry, Renewal and Notifications

Part 4 of a 4-part series on Supplier Lifecycle Operations. Tested on the Australia release.

Suppliers have to keep compliance paperwork current: insurance certificates, ISO certificates, tax forms, bank letters, signed policies. SLO handles this out of the box. Suppliers upload documents in the Supplier Collaboration Portal, ServiceNow tracks when each one expires, and the supplier is asked to renew before it lapses. On Australia, a supplier who misses the deadline is escalated automatically.

Two layers working together

Most of the confusion around supplier documents comes from not knowing which layer does what.

1. SLO document configuration decides what to collect. You define a Supplier Document Configuration (sn_slm_document_config) and the Supplier Document Types (sn_slm_document_type) under it. Find them under Supplier Lifecycle Operations > Administration > Document Configuration, or in the Source-to-Pay Workspace. You need sn_slm.manager or sn_slm.admin.

Field	Purpose
Required from	Which suppliers must provide the document
Generate task for	Whether to raise an Upload Document task for each supplier contact. Only appears when Required from is Everyone
Expiry days	How long a document stays valid after upload
Notify on upload / Upload recipients	Who is emailed when a document is uploaded
Notify on expiry / Expiration recipients	Whether an expiry notification is sent, and to which supplier contacts
Days to expiry	How many days before expiry that notification goes out. Only applies when Notify on expiry is Yes
View / Update / Admin access	Who can see and manage the document

2. Platform Document Management stores the files and tracks expiry. Uploaded files are stored as ds_document records with versions, linked to the supplier through sn_slm_document_references. When a document is uploaded against a type, its expiry date is set from the type's Expiry days. On Australia, supplier managers and contacts can also enter the expiry date themselves at upload. From then on, the expiry and renewal logic runs off that date.

In short: SLO defines the rules, and Document Management enforces them.

Australia tip: supplier contacts can now upload documents from the portal even when no document configuration exists. That's convenient, but documents uploaded that way won't follow a type's expiry and notification rules unless you set them up.

 

Who can upload

On the portal's Documents page, the New button appears only when both of these are true:

1. The user can create ds_document records. Out of the box that means the snc_external or snc_internal role, plus write access to the target folder if one is set. Supplier contacts get snc_external through sn_slm.contact.
2. ServiceNow can work out which supplier the user belongs to. It does this through SupplierCommonUtil().getSupplierID(), which checks in this order:
   1. the supplier cached in the session
   2. the contact's default supplier mapping
   3. the supplier whose company matches the user's Company

Testing trap: because the supplier is cached in the session, impersonating one supplier contact and then switching to another can leave the first supplier stuck. Log out between tests, or better, test with real supplier contact logins.

The lifecycle

If the supplier uploads a new version in time, the task closes and the clock restarts. If not, the task goes overdue, the document is marked Expired on its expiry date, and once the grace period runs out a supplier case is raised. All three timings are configurable, as the next section shows.

Configuring expiry monitoring on Australia

On Australia the timing is no longer hard-coded. Go to Supplier Lifecycle Operations > Administration > Supplier document expiration monitoring attributes (admin role). It opens a Decision Builder table with three attributes:

Attribute	Default	What it controls
Lead time	30 days	How many days before the expiry date the document upload task is created
Grace period	30 days	Extra time to complete the upload task after its due date. When it ends, a supplier case is created
Reminder frequency	7 days	How often email reminders go out during the grace period

Because it's a decision table, the values can vary by condition. Check which inputs the table exposes on your instance before promising document-specific timings. Defaults are from Configure document expiration monitoring attributes.

 

What runs behind it

On our instance, these are the pieces that do the work:

• Check supplier documents for expiry monitoring phase — a daily scheduled job that finds documents entering the lead-time window and calls the subflow create_or_update_document_upload_task.
• The renewal task — a Supplier Task (sn_slm_task, action type upload_documents) named "Document renewal request for {document}", assigned to the document owner, due on the expiry date and visible in the portal under My Tasks. If a document is uploaded with an expiry date already inside the window, an async business rule creates the task immediately.
• Close Document Tasks on Upload — a flow that closes the task when the supplier uploads a new version.
• Check the expiry of supplier documents — a daily job that marks the supplier's document reference as expired.

Notifications

Moment	Notification	Recipient
Document uploaded	Notify on supplier document upload (sn_slm.document.uploaded), if enabled on the type	Upload recipients on the type
Before expiry	Document Expiry Warning (ds_document.expiry.warning)	Document owner
During grace period	Reminder emails at the configured reminder frequency	Task assignee
Renewal task overdue	Supplier doc task overdue (sn_so.supplier_doc_task_overdue)	Task assignee
Document expired	Document Expired (ds_document.expired)	Document owner
Document expired (SLO)	Notify on supplier document expiry (sn_slm.document.expired), only if Notify on expiry is Yes on the type	Expiration recipients on the type

Worth checking on your instance: whether the supplier gets an email at the moment the renewal task is created. The general supplier-task email may not cover the upload_documents action type. If it doesn't, suppliers find the task in the portal or through the expiry warnings, and you may want to add a notification.

Internal review and approval (optional)

Uploads don't create tasks for your internal team by default. To review supplier documents before they're published:

1. Create a Document Approval and Review Rule (ds_approval_revision_rule) with a condition on ds_document.
2. Add Reviewers and/or Approvers to the rule.

When a document is created, the Add Reviewers and Approvers business rule (PlatformDocRuleUtils) checks every active rule's condition and adds users from the matching rules. Versions then move to Awaiting review/approval, which starts the Review and Approval Workflow for Document Version. With no matching rule, versions are published automatically.

Practical recommendations

• Set up document types first. Expiry days, generate task and recipients drive everything downstream.
• Tune the expiration monitoring attributes. The 30/30/7 defaults suit most documents, but agree lead time and grace period with procurement before go-live.
• Always fill in Expiration recipients. Otherwise only the document owner is notified, and if that contact leaves the supplier, nobody gets the reminder.
• Decide whether the renewal task should send its own email. Add a notification if suppliers need one.
• Check the escalation playbook. On Australia, a missed grace period creates a supplier case. Make sure the case lands with a team that will act on it.
• Add review rules for high-risk documents, such as bank letters and insurance, if your team must validate them before they count.
• Test as a real supplier contact, not through impersonation chains.