Business logic

Moltaro business logic has two layers. Declarative rules are single expressions in the Moltaro expression language, configured on the entity definition and validated by the server before they are saved: field behavior, validation rules, statements, presentation rules, and calculated fields. See Declarative logic and the expression language. Trusted C# is procedural logic authored in the workspace Net Operation Project using the Moltaro .NET SDK programming model: validation and before-save mutation functions, triggers, actions, commands, jobs, schedules, and HTTP endpoints.

Start declarative. Expressions are cheaper to author, checked against the schema, and enforced by the server save pipeline. Move a rule to C# when it needs additional reads, external systems, or orchestration.

Choosing a surface

You need	Use
Show, require, or lock a field conditionally	Field behavior expressions
Reject a save that breaks a business rule	Validation rules, or a C# validation function when the check needs code
Constrain the candidates of one Reference from current and candidate fields	Reference Eligibility; active rules pre-filter Forms and Table filters and remain authoritative at save
Render extra read-time text in Table or Card surfaces	Display fields
Derive a stored value from other fields	Calculated fields, or a C# before-save mutation function beyond formulas
Name a record fact for filters, views, and cards	Statements
Compute the record title and subtitle	Presentation rules
Let users run an operation from the record UI	Actions
Run a synchronous operation from an API client	Command functions
Start and observe background work over the API	Job functions with API enqueue
React to record changes after they commit	Triggers
Run recurring work on a timer	Function schedules
Receive calls from an external system	HTTP endpoint functions
Give trusted C# an outbound credential without putting it in source	Managed secrets

The C# async keyword does not decide whether a caller waits or receives a job. Function contract, binding source, publication kind, and invocation route do. Use the machine-readable decision table in Asynchronous operations and polling before building an API client or agent workflow.

Moltaro has no separate outbound-webhook feature. To notify an external system, make the outbound call from a C# trigger or global function.

Where it lives in the product

Authoring pages are in the Constructor area, group Automation & logic:

• Development — the “Business Logic Development” page, where C# logic is authored; it offers Studio and NET Project modes.
• Function Catalog — discovered functions, versions, and bindings.
• Function Schedules — CRON schedules bound to global functions.

Monitoring pages are in the Administration area, group Monitoring:

• API Functions — command and API-enqueue publications with their enable/disable state.
• Function operations — queue depth, recent runs, failed or retrying jobs, and focused run details.
• HTTP Endpoints — inbound endpoint exposure, authentication mode, and secrets. Endpoints are disabled until an administrator enables them.

Calling business logic over the API

Published functions are invoked through the Runtime API:

POST /api/workspace/commands/{functionKey}
POST /api/workspace/functions/{functionKey}/enqueue
GET  /api/workspace/functions/jobs/{jobId}
POST /api/workspace/functions/jobs/{jobId}/cancel

Inbound HTTP endpoint functions receive requests at /api/workspace/inbound/{endpointKey}/{**path}. See HTTP endpoints for the request, authentication, and response contract. Published commands, API jobs, and UI actions are documented in the Runtime API reference; declarative rules are managed and validated through the Configuration API reference.

In this section

• Declarative logic — the no-code surfaces and when each applies.
• C# business logic — the Net Operation Project workflow.
• Managed secrets — write-only credentials, lifecycle, trusted C# access, and safe agent usage.
• Entity-scoped logic — validation, before-save mutation, and trigger functions.
• Global logic — functions not owned by one record.
• Commands and API functions — direct invocation from API clients.
• Actions — user-triggered UI operations.
• HTTP endpoints — inbound webhooks.
• Schedules — CRON-based recurring runs.
• Operations — run history, jobs, and diagnostics.

For the workflow-level view, see Automation and business logic in the user documentation.

For the cross-surface execution lifecycle, see Asynchronous operations and polling.