Field Types
Freshsales offers Text (single line, max 255 chars), Paragraph (multi-line, max 8000), Number (integer), Decimal, Currency, Dropdown (single value), Multi-select Dropdown, Checkbox, Date, Date and Time, URL, Email, Phone, Lookup (reference to another record), and Auto-number. Pick the narrowest type that expresses the data — a “country” field as Dropdown beats free-text every time because filters, deduplication, and reporting depend on consistent values. A common mistake: storing money as Text “for flexibility”; you cannot sum, average, or convert currency without the Currency type.
Usage in Views
Custom fields drive list filters, list columns, segmentation views, and report dimensions. Design fields with reporting needs in mind from day one. A field that looks innocuous at creation (Lead Source as text) costs months of analyst time later when Marketing wants conversion-by-source charts and the data is Google, google, GOOGLE, g00gle, unknown. Switch to Dropdown the day you create the field, not the day someone asks for the report.
Lookups
Reference fields point to other Freshsales objects (Account, Contact, Deal, Custom Module). They build relationships between custom modules — a Subscription custom module can lookup to Account and Contract. Be careful with N-level reference depth. Two hops are fine (Deal -> Account -> Industry), three hops start to confuse the UI (a list view that shows three-level lookup columns is hard to scan), and four hops break filter performance noticeably on tenants over 100K records.
// Read a deal with related account via API
fetch(`https://${domain}.myfreshworks.com/crm/sales/api/deals/${dealId}?include=sales_account`, {
headers: { Authorization: `Token token=${apiKey}` }
});Layouts
Section fields on the form by lifecycle stage rather than by field type. A typical Account form has sections for Identification (name, domain, industry), Engagement (last activity, owner, health score), Contract (renewal date, MRR, contract end), and Internal Notes. Role-based field visibility lets Sales see commission fields that Support shouldn’t, and Support see escalation contact fields that Sales doesn’t need. Hide rarely-used fields from the default view (Admin -> Field Layouts -> Per-Role Layouts) — clutter is the enemy of data quality because reps stop reading fields they’re not asked to update.
Governance
Catalog every custom field quarterly with four columns: field name, owner team, last-populated date, and used-in-reports count. Retire any field with zero population in 90 days or zero reports referencing it. A 400-field object where 50 fields actually matter is a clear signal — every form load is slower, every report builder dropdown is longer, and every new admin onboarding takes longer than it should. Use Admin -> Audit Logs to track who created each field and why; the description field is the cheapest documentation you’ll ever write.
Common Failure Modes
Three. First, free-text fields where Dropdown belongs — “industry” with 47 spelling variants destroys segmentation. Second, fields created for one report and never touched again — the report ran once, the field lives forever. Third, role-based visibility configured with allow-lists that aren’t updated when new roles are created; a new sales role inherits no custom-field visibility and reps complain that the CRM is “broken” when it’s just unconfigured.
Implementation Sequence
Before adding a new field, answer four questions in writing: what decision does this field inform, who populates it and when, what report uses it, when do we remove it. If any answer is “we’ll figure it out,” don’t create the field. The discipline saves hundreds of cleanup hours.
What to do this week
Export your current Account custom-field list with last-populated counts. Identify the bottom 20% by population and propose retirement. Even if half are saved by an objection, the other half disappears and the form gets cleaner.
