---
title: Supplier contacts
order: 9
updated: 2026-07-12
---

# Supplier contacts

A supplier is a firm; a *contact person* is a named individual who works there. Suppliers themselves carry no email address — their contact persons do. Every procurement message the app sends — RFQs, vendor follow-ups, purchase orders, PO follow-ups, and arrival receipts — is addressed to a specific contact person, so each supplier you actually trade with should have at least one. This page covers everything on the *Contact Persons* screen: adding, editing, searching, and deleting contacts, every field on the add/edit form, and why a delete can be blocked.

Contacts are stored per supplier — the same individual working with two different supplier firms is two separate records, one under each supplier. There is no shared address book.

## Before you start

- The supplier record must already exist. See [Suppliers](/docs/records/suppliers).
- Have the contact's name and email ready — those are the only two required fields. Phone, post, salutation, and the secondary email/phone are all optional.

## Open the contacts screen

1. Open *Data Entry* and click *Suppliers*.
2. Find the supplier in the list and click its contacts button on that row:
   - The button reads *Update Contacts* if you can add or edit suppliers (the *Add Supplier* or *Edit Supplier* permission).
   - It reads *View Contacts* if you have neither — you can still open the screen and read/search the list, but the *+ Add Contact Person*, *Edit*, and *Delete* controls are hidden.

The *Contact Persons* screen opens with `Supplier : <name>` shown above the list, a search box, the contacts table, and a *< Back* button that returns to the supplier list.

Just opening this screen requires the *View Suppliers* permission (`database.viewSupplierList`) — the same permission that gates the supplier list itself. Without it the list and search calls are refused server-side.

## Add a contact

Available only if you hold the *Add Supplier* permission (`database.addSupplier`) — the *+ Add Contact Person* button is hidden otherwise, and the server re-checks the same permission on save.

1. Click *+ Add Contact Person*. The *Add Contact Person* modal opens with two tabs: *Basic Info* and *Additional Details*.
2. Fill in the fields (see [Contact fields](#contact-fields) below). Only *Full Name* and a valid *Email* are required.
3. Click *+ Add Contact Person* at the bottom. On success you get an *Contact person added successfully!* toast and the list refreshes.

The new contact immediately becomes selectable wherever procurement asks you to choose a contact for that supplier — RFQ recipients, purchase orders, and receipts.

## Contact fields

The same fields appear on the *Add* and *Edit* modals, split across two tabs.

### Basic Info tab

#### Salutation

An honorific shown before the name. A dropdown with exactly these options: `None` (stored as empty), `Mr.`, `Mrs.`, `Ms.`, `Dr.`. Default `None`. The server re-validates the value against this exact list and rejects anything else, so a forged salutation cannot be saved. In the list the salutation is prepended to the name (e.g. `Mr. John Doe`).

#### Full Name

The contact's name. **Required** — must contain at least one non-blank character. Stored trimmed. This is the only field the fuzzy search matches against, and it is the label used everywhere the contact is referenced. There is no separate first/last name for supplier contacts — it is one free-text field.

#### Email

The contact's primary email address, and where their procurement mail is sent. **Required** and must be a valid email address. Stored lower-cased and trimmed. On the list each email has a click-to-copy tooltip.

> Validation note: on *Add* the whole payload is checked with the shared schema, so a malformed email is rejected. On *Edit* the frontend still blocks a bad email with the same check, but the server-side update only enforces that name and email are **present** (non-empty) and that the salutation is valid — it does not re-check email format on update. In normal use the form guards it; treat a clean email as your responsibility here.

#### Phone Number

Optional. Default empty. As you type, every non-digit is stripped and the remaining digits are grouped in blocks of four for display (e.g. `1900 9009 0090`); only the raw digits are stored. The input accepts up to `14` characters. There is no country-code or length validation beyond the digit-stripping — an empty phone is perfectly fine.

#### Post / Job Title

Optional free text (e.g. `Sales Manager`, `Purchase Head`). Default empty. Shown in its own *Post* column in the list. Purely descriptive — it does not affect routing or permissions.

### Additional Details tab

These two fields are optional extras kept on record; they are not used as the default send address (procurement mail goes to the primary *Email*).

#### Secondary Email

An optional backup email. If filled it must be a valid email address; leaving it blank is allowed. Stored lower-cased and trimmed. (As with the primary email, the format is enforced on *Add*; the *Edit* server path only stores whatever is sent.)

#### Secondary Phone Number

An optional second phone number. Same digit-only entry and four-digit grouping as the primary phone, up to `14` characters. Default empty.

## Find a contact

Type in the *Search contact persons…* box to filter the list. Search is debounced (it fires shortly after you stop typing) and runs a fuzzy match on the contact **name** only — it is scoped to the current supplier, so you only ever see that supplier's contacts. The matcher is forgiving: it handles exact matches, prefixes, word-order differences, subsequence and character-overlap matches, and it ignores punctuation and case, so partial or slightly-off spellings still surface the right person. Email, phone, and post are **not** searched.

Clear the box to return to the full list. While the box is empty the list loads in pages of `10` as you scroll (infinite scroll); while you are searching, up to `30` matches are shown at once and the infinite scroller is paused.

## Edit a contact

Available only with the *Edit Supplier* permission (`database.editSupplier`) — the *Edit* button is hidden otherwise and the server re-checks it on save.

1. Click *Edit* on the contact's row. The *Edit Contact Person* modal opens pre-filled, with the same *Basic Info* and *Additional Details* tabs.
2. Change what you need and click *Update Contact Person*.

Two things to know:

- **No-op guard.** If you save without changing any field, you get a *No changes detected.* warning and nothing is sent.
- **Applies going forward.** Editing a contact updates the single stored record. Documents already sent keep whatever address and details they went out with; the change affects future sends and any record that reads the contact live.

## Delete a contact

Available only with the *Delete Contact Person* permission (`database.deleteCP`) — the *Delete* button is hidden otherwise, and the server re-checks it. (This is the same *Delete Contact Person* permission used for customer contacts; it does not affect the parent supplier record.)

1. Click *Delete* on the row. A *Delete Contact Person* confirmation appears: *Are you sure you want to delete `<name>`? This action cannot be undone.*
2. Click *Delete* to confirm (or *Cancel*).

### When a delete is blocked

Before deleting, the server checks whether anything still points at this contact. If the contact is referenced by existing records, the delete is refused and a *where-used* screen opens listing exactly what still uses them, grouped by record type. The contact is **not** deleted. The record types that block a supplier-contact delete are:

- **Purchase orders** that were addressed to this contact.
- **RFQs / vendor invitations** where this contact was the vendor recipient.
- **Stock arrivals** linked to this contact.
- **Supplier quotation drafts** that reference this contact.

To remove the contact, first reassign or clear it on the listed records (for example, change the recipient on an open RFQ or PO), then run the delete again. This is a hard block — there is no "delete anyway" for supplier contacts. It exists so historical procurement records never end up pointing at a missing contact. See [Deleting records](/docs/records/deleting-records) for how the where-used screen works across the app.

## Common questions

### Which contact receives an RFQ or purchase order?

Whichever one you pick when you build the RFQ cart or the purchase order. The supplier firm has no email of its own, so you always choose a specific contact person. Add the people you deal with here first, then select the right one at send time. See [RFQ cart](/docs/procurement/rfq-cart) and [Create a purchase order](/docs/procurement/create-purchase-order).

### Can I email all of a supplier's contacts at once?

No. Procurement messages address one contact per send. If you want more than one person copied, use the *CC & BCC* options on the relevant template or send screen — see [Document templates](/docs/settings/document-templates). The secondary email stored on a contact is for reference only; it is not automatically added as a recipient.

### Can the same person be a contact for two suppliers?

Not as one shared record. Each contact person belongs to exactly one supplier. If an individual represents two supplier firms, add a separate contact under each.

### Why can't I delete this contact — it just shows a list of records?

The contact is still referenced by purchase orders, RFQs, stock arrivals, or supplier quotation drafts. The app blocks the delete and lists them so nothing is left pointing at a deleted person. Reassign or clear those records first, then delete. See [When a delete is blocked](#when-a-delete-is-blocked).

### Why do I only see *View Contacts*, and no add/edit/delete buttons?

Those controls are permission-gated. *+ Add Contact Person* needs *Add Supplier*, *Edit* needs *Edit Supplier*, and *Delete* needs *Delete Contact Person*. Without any of them the button on the supplier row reads *View Contacts* and the screen is read-only. Ask a firm administrator to grant the permission — see [Users and permissions](/docs/settings/users-and-permissions).

### Is the phone number validated?

Only lightly. The field keeps digits and drops everything else, and caps input at 14 characters — there is no country-code or minimum-length rule, and the phone can be left empty. Only the digits are stored; the spaced grouping is display-only.

### Do salutation or post affect anything?

No. Both are descriptive only. The salutation is prepended to the name in lists and documents, and the post shows in the list; neither changes who receives mail or what a user can do.