Conditions, statements, validation and calculations cover repeatable operational facts.
01 · Custom operations
Rules for normal work. C# for serious operations. Automation when events matter.
Moltaro keeps business behavior in the governed runtime: declarative DSL rules for everyday constraints, NetOperationProject C# for deep logic, and event-driven automation for work that should react after a real change commits.
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 carry rules, C# behavior and event automation without leaving the governed runtime.
A workspace-owned .NET project carries typed C# when configuration stops being enough.
Committed changes can become automation facts for downstream work.
Visible, required and editable conditions keep forms honest without adding browser-side scripts.
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.
NetOperationProject is the customer-facing C# surface.
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.
Automation rules belong on committed business events.
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, not in arbitrary browser scripts that are hard to secure or support.
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.
NetOperationProject 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 and C# are useful because they can work with the same records, Boards, reports, Entitlements, audit history and security model the team already uses.