OBJECT CRM
A flexible CRM built on custom objects
Companies, People, and Deals ship seeded. Objects you define get the same screens: 19 attribute types, server-computed formulas, saved views with and/or/not logic, lists, and provenance on every value.
One kernel
Seeded objects and custom objects run on the same rails.
Most CRMs hardcode three tables and bolt "custom fields" onto the side. Ishara is an object kernel: Companies, People, and Deals ship seeded, and an object you define yourself (Tenders, Mandates, Properties, LPs) gets exactly the same screens, saved views, automations, and email matching. Nothing about the seeded objects is special.
- 19 attribute types, from text, number, and money to select, date, and relationship
- Three modes per attribute: stored, formula (computed on the server), and relationship
- Formula fields behave like real columns: they filter, sort, and export
Saved views
A view is a saved question, not a filter you rebuild every morning.
Build nested and/or/not filter trees with 13 operators, pick a sort, and save the result as a table or a kanban board grouped by any status field. Scope decides who sees it: private for your own triage, shared with the team, or workspace-wide as the source of truth.
- Table and kanban layouts over the same saved view definition
- Nested and/or/not logic with 13 operators, not one flat filter row
- Private, shared, or workspace scope per view
Provenance
Every value knows where it came from.
A record page shows the fields, the panels, and the timeline. Behind each field, the kernel stores who or what wrote the value: a user, an import, an automation, a formula, AI, enrichment, or the system. When an enriched phone number disagrees with the one your colleague typed after a call, you can see which is which instead of guessing.
- Seven provenance sources tagged on every stored value
- AI-drafted values wait in a review queue; nothing lands on a record until a human accepts it
- Enrichment writes follow a policy you set, including suggest-into-review
The rest of the kernel
Lists, formulas, and honest totals.
Three details that separate a data model from a demo.
Lists with list-scoped attributes
A list is a working set of records with fields that exist only on that list: an "outreach wave" on a conference follow-up list, a "priority" on a bid shortlist. The working annotation stays on the list instead of becoming a permanent column on the whole object.
Formulas computed on the server
Formula fields are evaluated server-side, not in your browser tab, so they behave like stored data everywhere it matters: filter a view by one, sort a table on one, and it comes out in the export. "Days since last touch" can be a real column.
Group totals that refuse to mis-sum
When a group of records mixes currencies and a conversion rate is missing, the group sum splits into per-currency subtotals instead of adding riyals to dollars. The number you read on a board column is always one that actually exists.
What a flexible CRM with custom objects changes
Every team that outgrows a hardcoded CRM does the same thing first: they shoehorn. A government tender becomes a "Deal" with the buying entity in the company slot, the bid bond parked in a text field, and the closing date filed under "expected close". It sort of works, and every report downstream lies a little, because the schema and the business no longer describe the same thing.
Worked example: the mixed-currency column
A kanban column holds three deals: 900,000 QAR, 450,000 SAR, and 120,000 USD. A CRM that sums them anyway shows 1,470,000 of no particular currency, and that number flows into the forecast. Ishara's group sum splits by currency whenever a conversion rate is missing: three subtotals, each true, none invented.
In a flexible CRM built on custom objects, you stop shoehorning and model the thing itself. Define a Tender object: a money attribute for the bond, a date for closing, a relationship to the buying entity, a server-computed formula for days to close. It gets the same table, the same kanban, the same saved views, the same automations, and the same email matching as Deals, because it runs on the same kernel. There is no second-class tier of objects.
Views and lists are different tools, on purpose
A saved view is a standing question over all records of an object: "open deals over 500,000 QAR, in Qatar, not yet quoted", rebuilt live every time you open it. A list is a curated working set you add records to by hand or in bulk, and it can carry its own list-scoped attributes. Views are how the team agrees on what the data says; lists are how a subset of it gets worked this week. Most CRMs give you one and make it impersonate the other.
Provenance is what makes the rest safe
A kernel this open needs an answer to "who wrote this?". Ishara tags every stored value with its source: user, import, automation, formula, AI, enrichment, or system. Self-declared data never shares a column with verified facts, AI suggestions queue for human review before anything is written, and AI attributes and enrichment both operate under explicit write policies. The result is a CRM you can let automations and enrichment into without wondering, six months later, which numbers a person actually stands behind.
If your current system is a spreadsheet, the honest comparison is Ishara versus spreadsheets. If it is another CRM, imports covers the one-click Attio import, Pipedrive sync, and chunked CSV. And the fastest way to judge the kernel is to open the app and add a custom object to the seeded workspace yourself.
Frequently asked questions
Can custom objects do everything the seeded objects do?
Yes. Companies, People, and Deals are seeded records on the same kernel your custom objects use. A custom object gets the same table and kanban screens, saved views, automations, and email matching, with the same 19 attribute types.
What are formula fields, and where do they work?
A formula field is computed on the server rather than in your browser, so it behaves like stored data: you can filter a saved view by it, sort a table on it, and it comes through in exports. Stored, formula, and relationship are the three attribute modes.
Who can see a saved view?
You choose per view: private (only you), shared (people you share it with), or workspace-wide. Both table and kanban layouts work at every scope, and filters support nested and/or/not trees with 13 operators.
What does provenance on a value actually mean?
Every stored value is tagged with its source: user, import, automation, formula, AI, enrichment, or system. AI-drafted values sit in a review queue until a human accepts them, and enrichment writes follow the policy you set, including suggest-into-review.
Stop working the market blind.
The investors, the tenders, and the signals are in Ishara from day one. You bring the deals.
Free to start · 32,822 investors on day one · Qatar tenders live, more markets on the way