Conditions, statements, validation and calculations cover repeatable operational facts.
01 · Custom operations
Start with clear rules, then extend the process with C# and automation.
Use declarative rules for everyday constraints. When the process needs more, add C# in a Net Operation Project, build trusted custom pages in the Workspace UI Project, and trigger follow-up work only after the original change succeeds.
Start with rules that administrators can still understand.
Not every business decision should become custom code. Moltaro keeps common behavior close to the Entity Definition so it can be validated, imported, reviewed and changed without turning the operation into a bespoke app.
Runtime layers
Operational behavior
A record can combine rules, C# logic and event automation while access rules and history remain visible.
A workspace-owned .NET project carries typed C# when configuration stops being enough.
Committed changes can become automation facts for downstream work.
Trusted source-built custom pages extend the web app with workspace-specific screens, compiled and activated by Moltaro.
Visible, required and editable conditions keep forms honest without custom code.
Named predicates turn recurring business facts such as overdue, risky or ready into reusable runtime signals.
Object-level DSL checks block invalid saves before heavier C# business rules need to run.
Stored calculations and aggregates keep numeric operational values consistent as records and child rows change.
Use a Net Operation Project when configuration alone is not enough.
When a team needs logic that is too specific for configuration, Moltaro can compile a workspace-owned .NET project and run it through the same backend execution, security and diagnostics model.
Reject saves with structured errors, normalize values and derive fields before the record is committed.
Expose approved backend operations from forms or runtime commands while keeping permission checks and audit in the platform.
Run recurring work through CRON-style schedules, queueing, retries and run history.
Receive webhook-style calls or connect external systems through controlled backend contracts instead of ad hoc scripts.
Run follow-up automation only after the original change succeeds.
The direction is clear: automation rules should use the Resource EventBus as their backbone, reacting to durable facts from Entities, Boards, Entitlements and other runtime resources after the original operation has safely committed.
A real change commitsA record is created, a board item moves, an entitlement changes, or another runtime resource publishes a fact.01
A rule decides what mattersConditions can decide whether the event should start follow-up work, route responsibility or update another operational surface.02
The runtime performs the workAutomation can enqueue C# logic, move process state, update records or coordinate module behavior.03
The result stays explainableThe source event, actor, run and changed records remain traceable instead of becoming hidden side effects.04
Custom behavior should not bypass governance.
The point of custom operations is not freedom from the platform. It is freedom to implement deeper behavior while keeping Moltaro responsible for security, execution boundaries, history and operational diagnosis.
Business behavior runs in the backend runtime, and browser-side custom pages are trusted source-built code compiled and activated by Moltaro — not injected ad-hoc scripts.
Actions, functions, schedules and endpoints run through explicit contracts and platform authorization.
Operations teams can see failures, retries, slow runs, sources and correlations without reading server logs.
Net Operation Project source belongs to the workspace and can be downloaded, checked, built, and carried through deployment workflows.
The value is how it connects to the rest of the operation.
Rules, C# and custom pages are useful because they can work with the same records, Boards, reports, Entitlements, audit history and security model the team already uses.