A VP asks for a “rebate tracker” tied to deals. Two paths open. Path one: a Creator app with its own forms, its own reports, its own database, and a sync back to CRM. Path two: a custom module in CRM with a custom function. Both work in a demo. Only one survives 18 months of changes.
The decision isn’t “which is easier today.” It’s “where does this data want to live.”
Where data wants to live
Ask three questions before you pick.
- Is this data primarily consumed inside CRM workflows (lookups, reports, blueprints, forecast)? Yes → custom module + custom function.
- Is this data primarily consumed by non-sales users (finance, ops, HR) with their own approval flows and dashboards? Yes → Creator.
- Does the data need a heavy custom UI — forms with computed fields, multi-step wizards, role-specific submission flows? Yes → Creator, even if sales also touches it.
Most “I should build this in Creator” intuitions are wrong because they confuse “easier to mock” with “where the data lives.” If sales reports need to filter, sort, and aggregate by this data, it belongs in CRM. Period.
When Creator is the right call
- A standalone vendor onboarding portal with documents, signatures, and approval routing
- A field-service inspection app used by techs who don’t have CRM licenses
- An internal asset tracker that finance owns and IT supports
- A multi-stakeholder form with branching logic and custom calculations
In all of these, CRM data may flow in or out, but the system of record is the Creator app.
When CRM custom functions win
- A field calculated on save (territory bonus, weighted ARR, days-in-stage)
- A side effect on stage change (notify a Slack channel, create a task, push to ERP)
- A scheduled cleanup (close stale leads, archive dead opportunities)
- A blueprint-triggered enrichment
These all want to live inside CRM. Don’t build a Creator app to do them.
The hybrid trap
Teams pick Creator “because it’s flexible,” store deal-adjacent data there, then write sync functions in both directions. Now you have:
- Two systems of record, neither authoritative
- A sync that fails sometimes and creates ghost records
- Reports in Creator that don’t match reports in CRM
- A bus factor of one — the person who built the sync
If sync logic is more than 50 lines of Deluge and runs on every record update, you picked wrong. Move the data into CRM as a custom module. Take the loss. It’ll cost you a week now and save you a quarter later.
A clean custom-function pattern
Computed field on Deals: weighted ARR by stage probability and contract length, fired on update.
// Deluge custom function: compute_weighted_arr
// Bound to Deals update workflow rule
deal_id = input.id;
deal = zoho.crm.getRecordById("Deals", deal_id);
amount = ifnull(deal.get("Amount"), 0).toDecimal();
probability = ifnull(deal.get("Probability"), 0).toDecimal() / 100;
contract_months = ifnull(deal.get("Contract_Length_Months"), 12).toLong();
// Normalize to annual
annualized = (amount / contract_months) * 12;
weighted = annualized * probability;
// Stage multiplier (commit > forecast > pipeline)
stage = deal.get("Stage");
stage_multiplier = 1.0;
if(stage == "Closed Won") { stage_multiplier = 1.0; }
else if(stage == "Commit") { stage_multiplier = 0.95; }
else if(stage == "Best Case") { stage_multiplier = 0.6; }
else if(stage == "Pipeline") { stage_multiplier = 0.3; }
else { stage_multiplier = 0.1; }
final_weighted = weighted * stage_multiplier;
// Idempotent: only update if changed by more than $1
existing = ifnull(deal.get("Weighted_ARR"), 0).toDecimal();
if(math.abs(final_weighted - existing) > 1)
{
zoho.crm.updateRecord("Deals", deal_id, {
"Weighted_ARR": final_weighted,
"Weighted_ARR_Computed_At": zoho.currenttime
});
}Three things worth noting:
- Idempotent: only write if value changed materially. Saves API credits, prevents infinite loops if the rule re-triggers.
- Defaults via
ifnull. Empty fields don’t crash Deluge — they coerce, sometimes wrongly. - Audit field. Always stamp “computed at” so you can debug stale values without re-running.
When Creator is unambiguously right
A loan officer needs a 14-field intake form, with conditional branches, document upload, calculated rate, and a manager approval step. Two-week pilot. Salesforce-style page layouts inside CRM can’t do this without ugliness. A Creator form does it in a day.
The trigger to push approved loans to CRM is a single webhook from Creator. CRM treats it as a lead source. Clean boundary. No sync hell.
For the low-code patterns inside Creator that pair with this, see the Zoho Creator low-code guide.
Failure modes by path
If you picked custom module + function but should have picked Creator:
- Page becomes a wall of fields nobody scrolls through
- Conditional logic strains Canvas to the limit
- Non-CRM users need CRM licenses just to fill the form
- Reports are limited to CRM’s reporting engine, which is fine for sales and bad for finance
If you picked Creator but should have picked custom module:
- Sales pipeline reports require a second tool to be useful
- Lookups from Deals into Creator data are clunky cross-app calls
- Forecasting can’t see the data
- Every change to deal logic now requires syncing two systems
Both have a smell. Listen for it.
The decision checklist
- Primary user is in CRM daily? → CRM
- Data filters and rolls up in sales reports? → CRM
- Form has >12 fields with branching? → Creator
- Non-CRM users own the data? → Creator
- It’s an in-CRM calculation or side effect? → Custom function, never Creator
- You’re already arguing about sync? → Stop and pick one home
For the broader automation context, see Zoho CRM automation deep dive.
Bottom line
Creator is a separate app with its own data, UI, and users. Custom functions extend CRM behavior in place. Most teams overuse Creator because it’s marketed as flexible and underuse custom functions because Deluge looks scary. Default to custom function. Promote to Creator only when the form is really a form and the users aren’t sales. Never split a single dataset across both.
