Manage vendor portal contacts and access
Invite named contacts, assign appropriate roles and keep collaborator access project-scoped.
Vendor portal access begins with a named contact on a project vendor record. Contacts can represent the lead respondent or collaborators with different responsibilities. Their access is determined by the project relationship, active requests and supported portal role—not by the general directory profile. Maintain individual identities so invitations, submissions and audit events remain attributable.
Before you start
• Confirm each person’s name, work email and responsibility with the vendor.
• Apply least privilege: a person who only answers an RFI does not need every proposal or document action.
Step by step
1. Open project vendor contacts
From Projects → Vendors, open the vendor detail and find Contacts or portal access. Existing project contacts appear here even when they came from an earlier outreach step.
2. Create a named contact
Add the person’s name and email, then choose the supported role or permission level. Avoid shared inboxes unless the vendor has no attributable alternative and your policy permits them.
3. Add collaborators deliberately
Create a separate contact for each colleague who must contribute. Assign the relevant requests or responsibilities instead of forwarding another person’s secure invitation.
4. Send the actual request
A saved contact does not automatically receive portal access. Send an RFI, demo, proposal or other enabled request and verify the intended recipient in the send dialog.
5. Review and revoke access
Remove obsolete recipients, withdraw active assignments when appropriate and retain the audit history. For a replacement contact, add the new identity before resending the current release.
What happens next
• Tell vendor users to sign in with the exact invited email and the newest one-time code.
• Review portal contacts at each project stage change and before sharing sensitive commercial or signable material.
Troubleshooting
Saving a contact did not send an email
This is expected. Start the relevant request workflow and select the contact as a recipient.
A collaborator sees no assigned work
Confirm the person was included on that specific assignment and that its release is still active. A role alone does not assign every request.
A former contact can still use an old link
Withdraw or reassign active requests and remove their current access. An expired code cannot be reused, but request state should still be corrected.
Related guides
Related articles
Still stuck? Contact us →
