implementation strategy

[juan9]

We are implementing a CRM system for a medical device manufacturing company (Company X). The system will be used by sales representatives, system administrators, and team members managing sales rep shelf inventory.

Before Company X can sell or deliver a medical device to a hospital or healthcare facility (Company Z), the specific physician at that facility must be approved through a third-party Value Analysis Committee (VAC) system. Approval is required once per physician per facility.

When a sales representative delivers a device to a customer, they must pick the unit from their shelf inventory, and the system must verify that the target physician is approved before allowing the transaction.

Questions for CRM Architecture & Design:

1. Data Modeling & System Architecture:
• what is the optimal data model to handle this credentialing workflow?

• Should we use the standard Lead object for pending approvals, or transition directly to Accounts, Contacts (physicians), and a dedicated Custom Object for VAC approvals?

• Why is adding a simple "Status" or "State" field to the Company record insufficient for tracking approval logic in this scenario?

[Abhishek Pal · Accepted solution]

Hi @juan9 ,

I would not use Lead or a Status field on Company/Account to model this approval.

The VAC approval is a relationship-specific business record: a physician is approved for a particular facility. That means the approval belongs to the physician + facility relationship, not to either record individually.

Recommended data model:

Company X
-> Your organization

Customer Account
-> Company Y / hospital organization

Facility
-> If each facility is managed commercially as a separate customer entity, model it as an Account/child Account.
-> If it is only a physical site of the same customer, use the Account with the appropriate Location/Account Address model.

Physician
-> Contact

If a physician works at multiple facilities, use the appropriate Contact Relationship to associate that physician with those accounts/facilities.

VAC Approval
-> Dedicated approval/credential record referencing:

- Physician
- Facility/Account
- Approval status: Pending, Approved, Rejected, Expired
- External VAC approval ID
- Effective date
- Expiration date, if applicable
- Last verified date
- Source/system
- Rejection reason
- Integration status/audit information

Enforce uniqueness based on the actual business rule, for example:

Physician + Facility + Approval Type

if there should only be one applicable credential per physician/facility combination.

I would not use Lead for pending VAC approval.

Lead Management represents the pre-sales lifecycle for prospective customers and is intended to progress qualified leads into opportunities. VAC credentialing is independent of whether the physician or hospital is a sales prospect.

Likewise, I would not use sysapproval_approver as the primary data model for the external VAC approval. That table is intended for ServiceNow approval workflow participants. The VAC decision itself should be retained as business data in its own domain record.

Integration design:

Third-party VAC
-> IntegrationHub/REST
-> VAC Approval record
-> Approved/Rejected/Expired state

The external VAC system can remain the system of record while ServiceNow stores the approval status needed by the transaction.

At the point where the representative attempts to deliver the device:

1. Identify the physician.
2. Identify the facility.
3. Query the applicable VAC Approval.
4. Confirm Status = Approved and that the approval is currently valid.
5. Only then allow the order/inventory transaction to continue.

If approval is missing, pending, rejected, or expired, block the transaction and provide the user with the reason.

For the representative's shelf inventory, I would also evaluate the OOB inventory capabilities before creating another custom inventory model. If FSM/EAM is part of the licensed architecture, ServiceNow supports personal/field-agent stockrooms and inventory movement.

Why a Status field on Company/Account is insufficient:

Approval is not:

Company Y = Approved

It is:

Physician A + Facility 1 = Approved
Physician A + Facility 2 = Pending
Physician B + Facility 1 = Rejected
Physician C + Facility 1 = Approved

A single Account status cannot represent these combinations.

It also cannot properly maintain approval history, expiration, external VAC identifiers, evidence, or multiple physicians/facilities without adding repeating fields and complex logic to the Account record.

Therefore, I would recommend:

Account/Facility
+
Contact/Physician
+
Contact Relationship where required
+
Dedicated VAC Approval/Credential record
+
OOB inventory/order capability where licensed
+
REST/IntegrationHub integration with the external VAC platform

This keeps customer master data, sales lifecycle, credentialing, and inventory as separate concerns while still connecting them through references and workflow.

Lead should remain part of the lead-to-opportunity sales process and should not become a temporary storage object for regulatory/credential approval.

References:

https://www.servicenow.com/docs/r/customer-relationship-management/crm-customer-data.html

https://www.servicenow.com/docs/r/order-management/sales-and-order-management/lead-management.html

https://www.servicenow.com/docs/r/customer-service-management/c_ContactRelationships.html

https://www.servicenow.com/docs/r/platform-administration/table-administration-and-data-management/t...

Hope this helps!

If this response helped, please mark it as Helpful.
If it resolves your issue, please Accept it as Solution.

Kind Regards,
Abhishek Pal