A recent community post on application architecture made some excellent points about planning architecture early in Zoho Creator projects. The core message is right — Creator applications have a habit of growing organically into maintenance nightmares, and thinking about structure upfront pays dividends.

However, much of the advice in that post reads as general software engineering principles that don't account for Creator's specific capabilities and constraints. I wanted to put together a more grounded reference — covering what Creator actually offers, where the guardrails are and what good architecture looks like in practice on this platform.

1. Modular Architecture — The Cross-App Trade-Offs

Splitting into separate apps by domain is more viable in Creator than many developers realise — cross-app lookups, function calls and lookup-based reporting all work natively. But there are still trade-offs worth understanding before committing to a multi-app approach:

Practical reality: Cross-app lookups, reporting via lookup fields and cross-app function calls are all natively supported — which means the multi-app story in Creator is stronger than many developers assume. The remaining trade-offs are narrower but worth weighing: reports are still based on a single form (so complex cross-app analysis may need Zoho Analytics), permissions must be managed per app, and environments come with significant constraints — a 10-app cap, 800-component publish limit, 30-minute publish timeout, 30-version stacking limit in Stage, no data transfer between environments, and pre-production environments only receive 20% of your plan's usage limits for non-Deluge components (records, emails, schedules etc.) — though Deluge execution statements now get the full plan limit per environment independently. Portals, backup, audit trail and several other features aren't supported in development/stage at all. Every additional app multiplies this overhead. In most Creator projects, a well-structured single app with clear form naming conventions and organised sections will still be simpler to maintain — but the cross-app capabilities are more robust than many assume, so know the actual costs before deciding.

2. Workflow Orchestration — What Creator Actually Offers

Creator is sometimes described as supporting "event-driven architecture" — it doesn't have an event bus, message queue or pub/sub system, so that label overpromises. But it does have a broader workflow toolkit than many developers realise. Here's what's actually available:

What's still missing: There's no way to publish a custom event and have multiple independent subscribers, no automatic retry on failure, and no message queue. You also can't chain workflow types together natively (e.g. trigger a batch workflow from a form workflow). These gaps mean you'll need to design your own orchestration patterns — status-driven workflows, scheduled polling, or function-based coordination — rather than relying on platform-level event infrastructure.

The architectural takeaway: Creator's workflow toolkit is broader than "just form triggers" — between form workflows, schedules, batch processing, approvals, payments, blueprints, report action items and cross-app functions, there are real orchestration capabilities here. But it's not event-driven in any meaningful sense. Understanding what each workflow type can and can't do — and where they don't connect — is what lets you design reliable automation. Blueprints come closest to structured process orchestration for well-defined multi-stage flows. For everything else, "decoupled" in Creator means well-organised workflows calling reusable functions, not a pub/sub pattern.

3. The Platform Constraints That Actually Force Architectural Decisions

These are the walls you will hit, and they should inform your architecture from day one:

Key takeaway: Good architecture in Creator isn't about applying textbook patterns — it's about knowing where the platform will break and designing around those specific limits from the start. Every constraint above should inform decisions before a single form is created.

4. What "Good Architecture" Actually Looks Like in Creator

Rather than adapting enterprise patterns to fit Creator, here's what works in practice:

Naming conventions are your architecture. Creator doesn't have folders or modules for forms and reports — your form names, function names and field names are your organisational structure (functions do support namespaces for grouping, which helps). Adopt a consistent prefix convention early (e.g. CRM_Clients, CRM_Deals, OPS_Tasks, OPS_Timesheets) and enforce it ruthlessly. This gives you the logical separation of "modules" without the cost of multi-app architecture.

Summary tables over real-time aggregation. Don't calculate dashboard totals by querying thousands of records on load. Where you do need to aggregate at runtime, use Deluge's built-in aggregate functions (sum, count, average, min, max, median, distinct) directly in fetch tasks rather than looping through records — this is significantly more efficient. For larger datasets, create dedicated summary forms that get updated via workflows when source data changes, or use batch workflows to recalculate summaries on a schedule. This sidesteps the fetch limit and keeps reports fast.

Status-driven workflows over complex chains. Instead of workflow A calling function B which triggers workflow C, use a status field that progresses through stages. Each workflow responds to a specific status change. This gives you visibility into where a process is, makes failures recoverable and keeps individual workflows simple. For well-defined, repeatable processes, Blueprints are the native implementation of this pattern — they enforce stage progression with configurable transitions, transition owners, criteria and automated actions. Use blueprints where the process is predictable; fall back to manual status-field patterns where you need more flexibility (e.g. records that may re-enter a stage, or processes that don't follow a linear path).

Lookups over text duplication — but know the trade-off. Using lookup fields instead of storing text copies is good practice, but lookup fields in Creator have their own quirks. They display as record IDs in API responses, they add load time to forms with many lookups, the pick list only shows 5,000 choices (users must search beyond that), formula fields don't reflect changes made in lookup subfields across forms, and lookups can complicate imports/exports. Use them, but don't over-normalise to the point where every form has 15 lookups loading on open.

Final Thought

The best Creator architects aren't the ones who import the most patterns from other platforms — they're the ones who know exactly where the guardrails are and build accordingly. Architecture in Creator needs to be grounded in what the platform actually does and doesn't support.

Hope this serves as a useful reference. Happy to discuss any of these points further.