When should I use the Object Action client extension type?

• You need to react to Liferay Object events with logic that lives outside Liferay. • You're integrating another system (CRM, warehouse, analytics) with a Liferay Object.

How do I create a Object Action client extension?

1. Ship a sibling `oAuthApplicationUserAgent` extension and reference its code via `oAuth2ApplicationExternalReferenceCode`. 2. Set `resourcePath:` to the endpoint (relative to the OAuth app's `homePageURL`). 3. Optionally restrict which Objects trigger the action via `allowedObjectDefinitionNames`.

What fields are required on a Object Action client extension?

resourcePath (string): Handler path (relative to the OAuth app's `homePageURL`). oAuth2ApplicationExternalReferenceCode (string): Ref code of the paired `oAuthApplicationUserAgent`.

Object Action

Run custom logic when a Liferay Object event fires.

type: objectAction·Microservice·Liferay docs →

at a glance

Object Action (type: objectAction) is a Liferay Client Extension in the Microservice category. Registers an HTTP endpoint that Liferay calls when a configured Object event (create / update / delete) fires. Your service receives the payload and does what it likes — enrich, notify, replicate to another system, trigger a workflow. Object Actions are Liferay's webhook mechanism for Liferay Objects: they run out-of-process (in your microservice), so heavy work doesn't block the Liferay JVM. Every Object Action needs a sibling `oAuthApplicationUserAgent` extension so Liferay can authenticate the outbound call using OAuth 2.0. Restrict which Object types trigger the action via `allowedObjectDefinitionNames` — omit it and every Object type will fire the webhook.

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

# description

Registers an HTTP endpoint that Liferay calls when a configured Object event (create / update / delete) fires. Your service receives the payload and does what it likes — enrich, notify, replicate to another system, trigger a workflow. Object Actions are Liferay's webhook mechanism for Liferay Objects: they run out-of-process (in your microservice), so heavy work doesn't block the Liferay JVM. Every Object Action needs a sibling `oAuthApplicationUserAgent` extension so Liferay can authenticate the outbound call using OAuth 2.0. Restrict which Object types trigger the action via `allowedObjectDefinitionNames` — omit it and every Object type will fire the webhook.

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

# when to use

→You need to react to Liferay Object events with logic that lives outside Liferay.
→You're integrating another system (CRM, warehouse, analytics) with a Liferay Object.

# how to use

01Ship a sibling oAuthApplicationUserAgent extension and reference its code via oAuth2ApplicationExternalReferenceCode.
02Set resourcePath: to the endpoint (relative to the OAuth app's homePageURL).
03Optionally restrict which Objects trigger the action via allowedObjectDefinitionNames.

# required fields

field	type	description
`resourcePath`required	`string`	Handler path (relative to the OAuth app's `homePageURL`).
`oAuth2ApplicationExternalReferenceCode`required	`string`	Ref code of the paired `oAuthApplicationUserAgent`.

# optional fields

field	type	description
`name`	`string`	Display name.
`allowedObjectDefinitionNames`	`string[]`	Restrict to specific Liferay Objects.
`dxp.lxc.liferay.com.virtualInstanceId`	`string`	Scope to a virtual instance.

# example

client-extension.yaml

notify-slack:
    type: objectAction
    name: Notify Slack
    resourcePath: /actions/slack
    oAuth2ApplicationExternalReferenceCode: my-oauth-ua
    allowedObjectDefinitionNames:
        - C_Order

# related types

Usually shipped alongside Object Action:

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

# more in microservice

cd ..scaffold this type in VS Code →