Actions

An action is a block of one or more logical operations. Actions are the primary mechanism for building logic in Appfarm Create — they are used in apps, flows, and services to manipulate data, call external systems, and control application behavior.

An action is composed of action nodes, which are pre-built logic blocks that you configure and arrange in sequence. As the action runs, its nodes execute from top to bottom. The library of action nodes includes if statements, foreach loops, data operations, and advanced functionality such as generating PDFs and sending SMS.

Action nodes

Triggers

How an action is triggered depends on the context it belongs to.

In apps, actions are typically triggered by user behavior via an event handler, such as On Click. Actions can also be triggered on app load using the On App Load event handler, or automatically on a schedule using timers.

In flows, an action can be run from an app or another flow using the Run flow action node.

In services, an action is triggered by specifying it as the process action on an endpoint. Endpoints can be called by external systems, by a schedule, or from within the solution using Run Service.

In all three contexts, an action can call another action using Run action.

Action data

An action can define its own data — inputs it accepts, outputs it produces, variables it uses during execution, and data sources it operates on. These are scoped to the action and discarded when it completes.

Action Data SourcesAction VariablesAction Params

Debugging

Actions in apps are listed in Developer tools for Apps, which provides an overview of action execution and supports breakpoints for step-by-step debugging. Actions in services can be inspected using Developer tools for Services.

The Log to Console action node can be used to print data to the logs, and console.log statements in functions are also output. Action nodes that lack values for required properties are highlighted with a red indicator in the action editor, and App Health surfaces these as warnings.

Properties

Best practice

Use a verb when naming an action, for example Save event. This provides a quick description of what the action does. By including the object class event, it's easy to filter on actions which affect a specific object class.

Another alternative is to use the object class as a prefix, for example Event: Save. Since the list of actions is sorted alphabetically, this has the benefit of listing all Event-related actions together.

Property	Description
Name	A descriptive name.
Description	A longer description of the action. For your own reference.
Pause Render	Apps only. Pause UI updates while the action is running. By default, when an action is triggered from the UI, for example by clicking a button, any UI changes triggered by the action will run as they occur. This can result in a poor user experience, or degraded performance. By enabling pause render, any UI changes will not occur until the action has finished running.
Skip Render	Apps only. Do not update the UI after the action is finished. See Pause Render. As an example, say you have enabled skip render and are displaying an App Variable with the value 1. If the action updates the value to 100, the UI will continue to display 1 even after the action has finished running.
Parallel Execution	Apps only. Allow the action to fire multiple times in parallel. By default, an action will not run if the same action is already running for that user, which prevents accidental double execution. Only enable parallel execution on simple actions without heavy data processing — a common case is using On Hover Start and On Hover End to set a runtime boolean.
Private	Flows only. Set the action to only be available from other actions in the same flow.
Override Permissions	Flows only. Set permissions for which Roles should be allowed to execute this Action, overriding the permissions inherited from the flow.
Action Params	Add action params.