When should I use the Workflow Action client extension type?

• You need workflow-driven side effects (emails, integrations, approvals) that Liferay doesn't ship out of the box. • You are building a workflow marketplace product.

How do I create a Workflow Action client extension?

1. Ship a paired `oAuthApplicationUserAgent`. 2. Implement the handler at `resourcePath`; return workflow-compatible payloads.

What fields are required on a Workflow Action client extension?

resourcePath (string): Handler path. oAuth2ApplicationExternalReferenceCode (string): Ref code of the paired `oAuthApplicationUserAgent`.

Workflow Action

Custom action available in Liferay Workflow definitions.

type: workflowAction·Microservice·Liferay docs →

at a glance

Workflow Action (type: workflowAction) is a Liferay Client Extension in the Microservice category. Registers an HTTP handler that Liferay's Kaleo workflow engine can call as a step in a workflow definition. Workflow authors reference your action from their definitions the same way they reference built-in actions. Use Workflow Action when a workflow step needs to trigger a side effect Liferay doesn't ship out of the box — sending SMS, calling a payment API, updating a CRM, running an approval external to Liferay. Like every microservice extension, it runs out-of-process behind a paired `oAuthApplicationUserAgent` so long-running work doesn't hold up Liferay's workflow engine.

yaml type: workflowAction
category: Microservice
required fields: resourcePath, oAuth2ApplicationExternalReferenceCode
ships with: oauth-user-agent
liferay docs: learn.liferay.com →

# description

Registers an HTTP handler that Liferay's Kaleo workflow engine can call as a step in a workflow definition. Workflow authors reference your action from their definitions the same way they reference built-in actions. Use Workflow Action when a workflow step needs to trigger a side effect Liferay doesn't ship out of the box — sending SMS, calling a payment API, updating a CRM, running an approval external to Liferay. Like every microservice extension, it runs out-of-process behind a paired `oAuthApplicationUserAgent` so long-running work doesn't hold up Liferay's workflow engine.

Externalize business logic — actions, validation, workflow, notifications.

# when to use

→You need workflow-driven side effects (emails, integrations, approvals) that Liferay doesn't ship out of the box.
→You are building a workflow marketplace product.

# how to use

01Ship a paired oAuthApplicationUserAgent.
02Implement the handler at resourcePath; return workflow-compatible payloads.

# required fields

field	type	description
`resourcePath`required	`string`	Handler path.
`oAuth2ApplicationExternalReferenceCode`required	`string`	Ref code of the paired `oAuthApplicationUserAgent`.

# optional fields

field	type	description
`name`	`string`	Display name.

# example

client-extension.yaml

send-approval:
    type: workflowAction
    name: Send Approval
    resourcePath: /workflow/approval
    oAuth2ApplicationExternalReferenceCode: my-oauth-ua

# related types

Usually shipped alongside Workflow Action:

❯OAuth Application (User Agent)— Register a browser / SPA OAuth application.

# more in microservice

cd ..scaffold this type in VS Code →