Skip to content

Contacts — overview

Updated 31 May 2026·8 min read

Contacts are the people you do business with — prospects, customers, partners, anyone you want to keep a record of. This page covers what a contact is in TatvaCRM, what fields it has, who can see it, and how it relates to other modules.

What is a contact?

In TatvaCRM, a contact is a person you want to remember. That could be a prospect a sales rep just spoke with, a paying customer the support team is helping, a vendor in your supply chain, or a referral partner. Contacts are the atomic unit of the CRM — almost every other module (companies, deals, leads, tasks, activities) ultimately points back to a contact.

Contacts live in the Contacts module — left sidebar of your workspace. The default view is a sortable, filterable table; you can also switch to a kanban view (grouped by lifecycle stage) or a calendar view (grouped by next follow-up date).

Contacts vs Leads — which one?
Use Leads for prospects you haven't qualified yet — people who filled a form, attended a webinar, scanned a card. Use Contacts for people you've qualified and intend to do real business with. Leads convert into Contacts (one-way) once they're real. See Lead conversion.

Fields

Every contact has the following built-in fields. You can add custom fields on top — see Custom fields on contacts.

Identity

FieldTypeNotes
First nameText (≤100)Required
Last nameText (≤100)Required
SalutationText (≤20)Mr / Mrs / Ms / Dr / Prof
Job titleText (≤100)e.g. "Branch Manager"
DepartmentText (≤100)e.g. "Underwriting"

Contact channels

FieldTypeNotes
Email (primary)EmailValidated server-side
Email (secondary)EmailOptional second email
PhonePhoneOffice number — auto-normalised to E.164 with country default +91
Mobile phonePhoneDrives WhatsApp + SMS routing; auto-normalised
LinkedIn URLURLUp to 500 characters
X (Twitter) handleTextUp to 100 characters
Phone normalisation
When you save a phone, TatvaCRM uses libphonenumber to produce four derived fields per phone: phoneE164 (international format), phoneCountryCode (ISO-2), phoneType (mobile / landline / VoIP), and phoneExtension. You don't edit these — they are recomputed every time the original phone changes. Reports and exports use the E.164 form so phone matches work across sources.

Address

Address line 1 + line 2, city, state, country (ISO-2 from picker, e.g. IN), pincode. The country picker emits the ISO-2 code so reports group cleanly; the older free-form country field is still accepted but new writes should use the ISO-2 form.

Lifecycle and ownership

FieldNotes
Lifecycle stageWhere this contact is in your relationship. Default values: subscriber, lead, opportunity, customer, evangelist. Editable per tenant.
Lead statusOptional secondary status — useful when one lifecycle stage has multiple sub-states.
OwnerThe user responsible for this contact. Controls visibility — see below.
SourceWhere the contact came from — referral, website form, event, etc.
CompanyLink to a Company record. One contact can be linked to one company.
TagsFree-form labels for ad-hoc grouping. See bulk tag / untag operations.

Visibility and permissions

TatvaCRM uses a role + scope visibility model. Every role has a visibility scope on contacts — own, team, or everything:

  • own — you only see contacts where you are the owner
  • team — you see contacts owned by anyone in your team
  • everything — you see every contact in the workspace

System roles set defaults: Owner and Admin see everything, Manager sees team, Member and Viewer see own. Custom roles can pick any combination per module. See Roles and permissions.

Unassigned contacts
Contacts with no owner are visible to everything-scoped users only. If you import 500 contacts and forget to set an owner, your reps on own or team scope won't see them. The bulk-import flow has an Assign owner step for this reason — don't skip it unless you mean to.

API operations

Everything you can do in the UI is exposed via the REST API at /api/contacts. Notable endpoints:

MethodPathRequired permission
GET/contactscontacts:read
GET/contacts/:idcontacts:read
POST/contactscontacts:write
PATCH/contacts/:idcontacts:write
DELETE/contacts/:idcontacts:delete
POST/contacts/:id/restorecontacts:write
POST/contacts/bulk/deletecontacts:delete
POST/contacts/bulk/updatecontacts:write
POST/contacts/bulk/tagcontacts:write
POST/contacts/bulk/untagcontacts:write
Soft delete
Deleting a contact is a soft-delete by default — the record stays in the database with a deletedAt timestamp and can be restored within 30 days via the Restore endpoint. After 30 days, a background job hard-deletes. This protects against accidental deletion without leaving forever-old records around.

What next

Was this page helpful?
Anonymous · we read every response