FPL Action Design Guidelines

Documentation status: guide — see Maturity and evidence.

An action should represent an identifiable business or application capability, not an arbitrary bundle of code.

Good design

• name the intent rather than the technical detail;
• declare inputs, result, and errors clearly;
• validate preconditions before mutation;
• keep observable effects explicit;
• use events or processes when an operation exceeds a short call;
• do not embed secrets, endpoints, or retry policy in business scripts;
• keep reusable logic out of UI handlers.

Local or SDK

If logic requires an external library, complex orchestration, or strong operational constraints, prefer a published capability/SDK rather than a script that bypasses Runtime boundaries.