Request a document from a vendor
Attach a certifiable document type as a requirement on a specific vendor (or customer or employee), so the system creates a Docs Submitted record and emails the request.
When to use this
When you onboard a new vendor and need them to provide a particular insurance certificate, accreditation, or other compliance document. The same flow works for customer-side document requirements (e.g. evidence of identity) and employee-side requirements (e.g. driver's licence on file).
Once attached, the requirement persists — the system handles request, reminder, renewal and expiry automatically. You don't need to chase manually.
Prerequisites
- Certified Documents installed and configured
- The Certifiable Document type already exists in the library — see Set up a document type
- The vendor (or customer or employee) record exists in NetSuite
- The vendor has at least one contact with an email address, or the FC CD Default Contact field is set on the vendor record
Walkthrough
Walkthrough coming
A step-by-step Scribe walkthrough for this task is being recorded. Track its status in the Scribe register (internal).
Attach the requirement
- Open the vendor record in NetSuite (the same flow applies to customer and employee records).
- Go to the FullClarity entity subtab.
- Find the Required Docs sublist.
- Click New Required Doc (or Add Row, depending on your form).
- Set the fields on the new row:
- Document (Vendor) — pick the certifiable document type to require (the list is filtered to documents marked as required-from-vendor)
- Default Vendor Contact — the contact who'll receive the request email
- Default Vendor Contact Email — auto-populates from the contact, but can be overridden if the request needs to go to a different address
- (Optional) Override the request, reminder, renewal or rejection email templates on this specific requirement
- (Optional) Override Renewal Days if this vendor's contract specifies a different renewal window
- Save the requirement.
What happens next
Depending on the certifiable document type's operating workflow:
- Auto Send mode — a Docs Submitted record is created automatically in Initialized status, the signed upload link is generated, and the request email fires to the contact. The status transitions to Requested once the email is sent.
- Manual mode — a Docs Submitted record is created in Preparing Manual Request status. An internal user actions it (typically by opening the record and clicking a Send action) to fire the email.
From there, the system manages the rest:
- Reminder emails fire on a 7-day cadence until the document is received
- Once uploaded, the status moves to Received and the approval chain kicks in
- Renewals are auto-initiated N days before expiry — a new Docs Submitted record is created, linked back to the previous one via a renewal chain
- Expiry marks the original Docs Submitted as Expired once the end date passes without a renewal being approved
- Cancellation happens automatically if the vendor is made inactive — the Docs Submitted is moved to Cancelled and no further emails fire
Manually re-sending the request
If the original contact has changed or the request needs to go out again:
- Open the Docs Submitted record (on the Required Doc's child sublist).
- Change the contact or contact email if needed.
- Use the Resend Request action to re-trigger the email.
When the recipient declines
If the external party can't or won't submit the document, they can pick a decline reason on the upload page instead of uploading a file. The submission moves to Declined (5) and an internal reviewer is notified. Decline reasons are entity-type-specific — vendors see a different set from customers, who see a different set from employees.
What success looks like
- The vendor's FullClarity entity subtab shows the new Required Doc with its current status.
- A Docs Submitted child record exists — visible from the Required Doc's view page — in either Requested (Auto Send) or Preparing Manual Request (Manual) status.
- For Auto Send: the contact has received the request email with a working upload link.
Gotchas
- Document filter by entity type matters. Each vendor / customer / employee subtab shows the dropdown filtered to documents marked as required-for-that-entity-type. If your document doesn't appear in the list, check the Required From Vendor / Customer / Employee checkboxes on the Certifiable Document.
- Contact email is mandatory for Auto Send. Without an email, the request email can't send. The Update Missing Contact MR script will try to fall back to the entity's own email, then to the FC CD Default Contact on the entity record, then give up and log the gap. Set the contact up front.
- Same document can be required multiple times. Adding a second Required Doc for the same document type on the same vendor creates a parallel chain. Usually a mistake — Required Docs are intended to be unique per (document × entity).
- Required Doc with no Operating Workflow. If the Required Doc record is missing its Operating Workflow (rare, but possible after a manual data load), the post-deploy MR script will eventually default it to the certifiable document's operating workflow. To force the fix, open the record and save it.
- Renewal chains. When a renewal is auto-initiated, the new Docs Submitted is linked to the previous one. Don't expect the old submission to update — it stays at its terminal status while the new one drives the cycle.