Once deployed as a process, a function runs as an Orchestrator job. You can invoke it from several surfaces. A JavaScript function that declares a route has one more: it can also be called directly over HTTP.

In a Maestro process, add a Service Task and bind it to the deployed function:

The input and output schemas exported from your Input/Output models drive the binding UI, so typed fields appear directly in the mapping panel.

In Studio or Studio Web, add the Run Job activity and point it at the deployed function. The same exported input/output schema drives the argument mapping, so typed fields appear directly in the activity's input/output panels.

Start the function as a job:

Pass the package (release) and the input arguments in the request body. The job runs the function and returns its output through the standard job result.

Because a deployed function is an Orchestrator process, it can be started by any job trigger — scheduled, queue-based, or event/webhook-based.

A JavaScript function that declares a method and a path is also exposed as an Orchestrator HTTP trigger. Callers reach it at the trigger URL with a bearer token, and the platform passes the caller's identity to the function — which is what lets a Coded App use a function as its backend without ever holding a credential in the browser.

The request and the response are bounded on this surface: about 10,000 characters of input and about 512 KB of output. A job has no such limit, because it carries large payloads as attachments — so a function handling megabytes should be invoked as a job even when it also has a route.

This surface is specific to JavaScript functions; a Python function is always invoked as a job. See HTTP triggers and routing.

Every invocation runs as a job and is logged in Orchestrator job history with caller identity and timestamps. When invoked from Maestro, the run also emits trace spans — see Tracing and observability.