Source-to-Pay on ServiceNow, Part 3: How Suppliers, Companies and Contacts Really Link

[sachinbhasin11]

Suppliers, Companies and Contacts in SLO: How They Really Link

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

In SLO the supplier and the company are separate records, and they don't reference each other directly. The supplier is sn_fin_supplier. The company is core_company. The place where the two meet is the supplier contact, stored in vm_vdr_contact. Getting this right matters most when you bring supplier data in from an ERP, because the records have to be created in the right order.

This post covers what we learned about those links on a live implementation, plus the roles that decide who can do what.

At a glance

How supplier, company and contact link

The contact points at both the company and the supplier. The company and the supplier never point at each other.

What we learned on the engagement

1. A supplier contact needs a company first

Supplier contacts are created in vm_vdr_contact, which extends sys_user. Two fields on it matter most:

• Vendor is mandatory and references core_company. So for any new supplier you first check whether the company exists. If it doesn't, you create it, and only then can you create the contact.
• Organization references sn_fin_supplier and tells you which supplier the contact belongs to. sn_fin_supplier does not extend core_company.

This is why supplier and company can live independently. The contact record is the point where they are tied together.

On our instance, the flow that creates the company for a new supplier out of the box is the Supplier Onboarding Playbook. If you load suppliers through an integration instead of onboarding them, your import has to create the company itself.

2. One contact can serve several suppliers

The link between a contact and a supplier is held in sn_slm_contact_m2m_supplier, not on the contact. That allows one person to be the contact for more than one supplier, which is common in group companies. ServiceNow documents this as a feature you enable ("Enable M2M mapping between supplier contact and suppliers"), so check its conditions on your release.

When it's on, a multi-supplier contact sees a company drop-down on the Supplier Collaboration Portal and chooses which supplier a request is for.

3. Locations are reused, not copied

sn_slm_m2m_location has only a few fields: the supplier, the location (a cmn_location record), and a category that says what type of site it is, such as headquarters or invoice address.

Two consequences:

• When loading supplier data from an external system, create the location in cmn_location first, then reference it here.
• cmn_location has its own company field. A location that already belongs to another company can still be mapped to a different supplier through sn_slm_m2m_location, so you don't need a duplicate location record.

4. Email domains aren't unique

sn_slm_email_domain has no duplicate-key rule. The same domain can be stored against several suppliers. That's fine for shared domains such as gmail.com, but it also means a domain alone can't reliably identify one supplier. Keep that in mind if you build email routing on it.

5. Supplier cases are Task records

sn_slm_case extends sn_spend_sdc_service_request, the Finance Case table from Common Service Delivery, which descends from Task. Standard task tooling therefore applies to supplier cases.

SLO roles: who can do what

The SLO roles live in the Supplier Common Architecture scope (sn_slm). They build on each other, so pick the smallest one that does the job.

Role	What it allows	Contains
sn_slm.admin (Supplier Administrator)	Create, view, update and delete all suppliers, cases and tasks	sn_slm.manager, sn_fin.supplier_payment_info_write, awa_admin, decision_table_admin, sn_kpi.admin and others
sn_slm.manager (Supplier Manager)	Everything an owner can do, across all suppliers; create suppliers through the playbook	sn_slm.owner
sn_slm.owner (Supplier Owner)	Everything a fulfiller can do, but only for the suppliers they own; create suppliers through the playbook	sn_slm.fulfiller
sn_slm.agent (Supplier Agent)	Create cases and tasks; view all suppliers, cases and tasks; update all tasks and assigned cases	sn_slm.fulfiller
sn_slm.fulfiller (Supplier Fulfiller)	Create tasks; view and update assigned cases and tasks and the suppliers related to them	awa_agent, workspace_user, sn_fin.finance_user and others
sn_slm.contact (Supplier Contact)	Submit requests from the supplier catalog and complete assigned tasks in the Supplier Collaboration Portal	snc_external, sn_fin.supplier_payment_info_read

Roles and contained roles from Components installed with Supplier Lifecycle Operations.

Three things that caught us out:

• Internal roles can't use the portal. Users with the Supplier Manager, Fulfiller or Owner roles cannot access the Supplier Collaboration Portal. Test the portal with a real supplier contact, not an internal user.
• Portal access comes from snc_external. sn_slm.contact contains snc_external, which is what lets a supplier contact in. If a contact can log in but sees nothing, check that both the role and the supplier mapping are in place.
• Bank details have their own roles. Supplier bank accounts are held in sn_fin_supplier_payment in Finance Common Architecture. Read and write access is controlled by sn_fin.supplier_payment_info_read and sn_fin.supplier_payment_info_write, so decide deliberately who gets them rather than relying on the SLO roles alone.

Key takeaways

• Create in this order when loading suppliers: company (core_company), supplier (sn_fin_supplier), location (cmn_location), then the contact (vm_vdr_contact) and its links.
• Contact-to-supplier links live in an sn_slm many-to-many table, which is what makes multi-supplier contacts possible.
• Don't rely on email domains to identify a single supplier.
• Test the portal with a real supplier contact. Internal SLO roles can't access it.

Next in the series: Part 4 covers supplier document management: expiry, renewal tasks and notifications.