AUTOMATIONS
CRM automation with webhooks, an API, and a paper trail
Rules go live by publishing a version. Runs are state machines you can open, waits included. Failures land in a dead-letter queue, routing happens in the database with audit counters, and the mail outbox admits when it is stuck.
A rule that fires while you are still editing it is a bug generator
Most CRM automation ships as a live toggle: flip it on, edit in place, and hope nobody hits the half-finished branch. Ishara's rules are versioned instead. You edit a draft, and publishing a version is the act that turns the rule on. The automations list shows exactly which version is live and how its runs are doing, so "what was the rule doing last Tuesday" has an answer.
- Publishing is the on switch, so a half-edited rule never fires
- Every change is a new version, and the history stays visible in the list
- Values an automation writes are provenance-tagged, so you always know a field was set by a rule and not a person
Inspectable runs
Every run is a state machine you can open.
A run is not a log line. It is a sequence of states you can step through after the fact: which trigger fired, which steps executed, where a wait paused the run, and how it ended. Debugging an automation means reading what happened, not reconstructing it.
1. Trigger
A record event, an inbound webhook, or a schedule starts the run.
2. Steps and waits
Steps execute in order. A wait pauses the run, and it resumes on time with its state held.
3. Done, or dead-letter
Success completes the run. Failure parks it in the dead-letter queue with its state intact, for inspection instead of disappearance.
Routing and territories run in the database, not in a browser tab
Lead routing that runs in the client has a failure mode every sales team knows: two records arrive at once, both grab the same "next" rep, and the round robin quietly stops being round. Ishara assigns ownership in the database itself, on insert, so assignment cannot race the UI and never depends on someone having the app open.
Three modes cover the real cases: round robin across a pool, fixed owner for a segment, and territory, where rules match on country, states, and cities. Beside the rules sit read-only audit counters: per rule and per member, how many records were assigned and when the last one landed. The counters are the paper trail for how work was distributed, which ends the "I never get the good leads" argument with numbers instead of anecdotes.
Worked example: one routing week
Monday, you publish version 3 of the inbound-leads rule: Qatar records go to Sara, Saudi Arabia to Omar, and the UAE to a two-person round-robin pool. Over the week, 40 payloads arrive through the inbound webhook from your website form. The counters read Sara 15, Omar 13, and the pool 6 and 4. Two runs fail on a malformed payload and sit in the dead-letter queue with their state intact, so you can see exactly which two records were affected and fix the source. Nothing was assigned twice, and nothing vanished.
Routed records land in the same object CRM your views and pipelines already read, so a territory change shows up everywhere at once.
Webhooks & API
The workspace has doors in both directions.
CRM automation is only half the story if outside systems cannot reach in, and yours cannot hear out.
Inbound webhooks
Every workspace can expose endpoints that outside systems post to, so a signup form, a billing alert, or a partner system can create the event that starts a run. No polling, no middleware subscription.
Outbound webhooks
Record events deliver to URLs you register, so your own services learn about a stage change or a new record the moment it happens instead of on the next sync.
API keys with in-app docs
Create and revoke keys inside the app, with the API docs sitting right beside them. You never leave the product to find out what an endpoint expects.
The mail outbox tells you when the queue is stuck, not just how long it is
Automations that send mail write into an outbox, and the outbox panel is deliberately read-only: it reports, it does not let anyone hand-edit a queue. The interesting part is what it reports. A queue showing zero pending mail can mean two very different things: nothing to send, or a sender that died mid-claim and stranded everything behind it.
Ishara checks the age of the oldest queued message against the mail worker's cadence. The worker runs every few minutes; if the oldest queued message has waited longer than that, the panel says so in plain text. Mail sitting at "Sending" past its window points the same way. A quiet queue and a stuck queue finally look different.
Scheduled digests use the same rail: instead of a ping per event, a digest sends one summary on the cadence you set, so a busy pipeline becomes one readable email. Sequenced outreach mail is its own feature, on the email page.
The same design bias runs through the whole surface: versions over toggles, state machines over log lines, database assignment over client races, and a dead-letter queue over a dropped run. If you want automation whose failures write to your dashboards too, analytics reads from the same workspace. And if your rules are currently trapped in another tool, the imports page covers getting your data here first. The fastest proof is the product: open the app, publish a one-step rule, and read its first run end to end.
Frequently asked questions
Does Ishara have an API and webhooks?
Yes, both directions. Outbound webhooks deliver record events to URLs you register, inbound webhooks let outside systems post events in to start runs, and API keys are created and revoked inside the app with the docs beside them.
What happens when an automation run fails?
The run lands in a dead-letter queue with its state intact: the trigger, the steps that executed, any waits, and where it stopped. Nothing is silently dropped, and the mail outbox separately flags a stuck queue by checking the age of the oldest queued message against the sender's cadence.
How does lead routing and territory assignment work?
Assignment runs in the database on insert, so it cannot race the UI or depend on an open browser tab. Rules come in three modes: round robin across a pool, fixed owner, and territories matched on country, states, and cities. Read-only counters record how many records each member received and when, as an audit trail.
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