Source-to-Pay on ServiceNow, Part 2: The SLO Data Model in 15 Tables

[sachinbhasin11]

The SLO Data Model: 15 Core Tables Around One Supplier Record

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

Supplier Lifecycle Operations rests on 15 core tables in the Supplier Common Architecture scope (sn_slm). Each starts with sn_slm. Surprisingly, none of them hold the supplier itself.

The supplier record is sn_fin_supplier, in the Finance Common Architecture scope (sn_fin). Most sn_slm tables point back to it. So sn_slm doesn't answer "who is this supplier". It answers everything around that:

• who we talk to at the supplier, and who owns the relationship on our side
• where they operate
• what they sell
• how we classify them
• which documents we hold from them
• how we work on requests and issues with them

At a glance

SLO data model · 15 tables in 5 groups

The five groups all reference the supplier record in sn_fin. Nothing in sn_slm duplicates it.

 

The 15 core tables

#	Table	Label	Group	Why it is used	Key fields and links
1	sn_slm_contact_m2m_supplier	Supplier contact	Relationships	Links people at the supplier to the supplier record and marks who is primary. One contact can serve more than one supplier.	supplier → sn_fin_supplier; supplier_contact → vm_vdr_contact; primary_contact; default_supplier; importance
2	sn_slm_supplier_m2m_internal_stakeholders	Internal Stakeholders	Relationships	Records who inside your company owns or works with each supplier, and in what role.	supplier; user → sys_user; relationship_type; importance
3	sn_slm_m2m_location	Supplier Location	Relationships	Lists the sites a supplier operates from, including headquarters. Cases and tasks can point at a specific site.	supplier; location → cmn_location; is_headquarters; location_category; external_unique_id
4	sn_slm_email_domain	Supplier Email Domain	Relationships	Stores the email domains that belong to a supplier, such as acme.com. Used to recognise which supplier a person or an email belongs to.	domain; supplier
5	sn_slm_product_code	Product Code	Classification	The catalogue of product or service codes that describe what suppliers sell, with a hierarchy level.	code; name; level
6	sn_slm_code_m2m_supplier	Supplier Product Code	Classification	Tags each supplier with the product codes it supplies, so you can find suppliers by category.	supplier; product_code → sn_slm_product_code; external_unique_id
7	sn_slm_segmentation_rule	Segmentation rule	Segmentation	Defines a rule that groups suppliers automatically, such as strategic or high-risk, from a condition on a table. Runs on a schedule.	segmentation_table; segmentation_condition; segmentation_entity_field; frequency; next_run_time; state
8	sn_slm_segmentation_rule_action	Segmentation rule action	Segmentation	What happens when a rule matches a supplier. A rule can have several actions.	segmentation_rule; action_type; script
9	sn_slm_m2m_segmentation_rule_entity	Entity segmentation rule	Segmentation	The current result: which suppliers a rule has placed in its segment, and whether that was automatic or manual.	segmentation_rule; supplier; entity_table; creation_type
10	sn_slm_m2m_segmentation_rule_entity_history	Segmentation rule history	Segmentation	An audit trail of past segment membership, so you can see how a supplier's classification changed.	segmentation_rule; entity_table
11	sn_slm_document_config	Supplier Document Configuration	Documents (setup)	Says which documents to collect from which suppliers and when, for example from all new suppliers in a region. Holds access and notification rules.	supplier_create_condition; when_to_run; required_from; generate_task; access via user_criteria
12	sn_slm_document_type	Supplier Document Type	Documents (setup)	Defines each kind of document, such as an NDA, tax form or certificate: how long it stays valid, who is told when it expires, and who may see it.	document_config; type; expiry_days; notify_on_expiry; generate_task; required_from; catalog_item
13	sn_slm_document_references	Document references	Documents (records)	The actual document held for a supplier, tracked against its type, with flags for expired or out of sync.	extends ds_document_references; doc_type → sn_slm_document_type; out_of_sync
14	sn_slm_case	Supplier Case	Cases and tasks	The work record for any supplier request or issue, such as onboarding or a bank details update. Can run on a playbook.	extends sn_spend_sdc_service_request; supplier; playbook; related_location; root_cause; resolution_notes; is_visible
15	sn_slm_task	Supplier Task	Cases and tasks	A unit of work under a case, such as collecting a document or approving a change, for an internal team or the supplier.	extends sn_spend_sdc_service_task; task_audience; document_reference; related_location; action_table; action_record

Field names are as seen on our Australia instance. Check them on yours before relying on them in scripts. Note that ServiceNow's documentation lists the contact link table as sn_slm_supplier_m2m_contact; confirm which name your release uses.

 

What to know about each group

Relationships. The contact person is not stored in sn_slm. It lives in vm_vdr_contact, which extends sys_user. sn_slm_contact_m2m_supplier only links that contact to one or more suppliers. Locations work the same way: the site is a normal cmn_location record, and sn_slm_m2m_location attaches it to the supplier. Part 3 covers both in detail.

Classification. Product codes form a hierarchy. Load your code catalogue (for example UNSPSC or your own category tree) before you map suppliers to codes, because sn_slm_code_m2m_supplier references it.

Segmentation. Four tables work together. The rule defines the condition and schedule. The action defines what happens on a match. The entity table holds current membership. The history table keeps the audit trail. Because rules run on a schedule, segment membership is not instant after a supplier changes.

Documents. Split into setup (configuration and type) and records (references to the actual files). The files themselves live in the platform's Document Management tables. Document configurations and document types extend sys_metadata, so they are application files: they are captured in update sets and move between instances like any other configuration. Part 4 covers the expiry and renewal lifecycle.

Cases and tasks. sn_slm_case extends sn_spend_sdc_service_request, the Finance Case table from Common Service Delivery, which in turn descends from Task. That means standard task features such as SLAs, assignment rules and Advanced Work Assignment all apply to supplier cases.

Key takeaways

• The supplier is sn_fin_supplier in sn_fin. The 15 sn_slm tables describe everything around it.
• Contacts and locations are platform records (vm_vdr_contact, cmn_location), linked through sn_slm many-to-many tables.
• Supplier cases are Task-based, so your existing task tooling applies.

Next in the series: Part 3 looks at how suppliers, companies and contacts actually link, and at the SLO roles.