Request Publish

The Request Publish workflow provides a structured approval process for content publishing. Authors submit a publish request directly from the Experience Workspace editor. The designated approvers receive an email notification with a link to review the content and either approve or reject it.

The workflow consists of two components working together:

Request for Publish Plugin - an Experience Workspace plugin used by authors to submit publish requests
Publish Requests App - an Experience Workspace app that serves both authors and approvers
- Approvers see an inbox of requests they can manage.
- Authors see a list of their own submitted requests, which they can resend or withdraw.

Email notifications are sent via a backend worker managed by Adobe and is provisioned per customer. You bring your own email provider for full control over the sender identity.

You can use this workflow two ways: through the plugin and app described below, or by driving it conversationally in Experience Workspace Chat mode (see the section Agentic Mode (Assistant)).

Setup

The Request Publish workflow requires three steps:

Getting onboarded by your AEM Engineering contact to configure your org and site
Configuring your Experience Workspace site to enable the plugin and app
Setting up the required user permissions.

Step 1: Get onboarded

Your org and site needs to be onboarded in order to use the plugin. To get started, reach out to your Adobe contact with the following information:

Your Experience Workspace org and site - so that your site can be registered to use this feature
Allowed email domains - the email domains permitted for approvers, CC recipients, and authors in your workflow. If your workflow involves contributors from other organizations, provide the additional domains you want to allow (e.g. partner.com, agency.com). Matching is case-insensitive.
Your email provider - the email service or API your organization uses to send mail including the following information
- apiUrl - Publicly accessible API URL that implements your email provider
- apiKey - API Key to access the endpoint (will be passed as x-auth-api-key header)
- fromEmail - The from email you would like the email to be sent as (eg: noreply@example.com)
- fromName - The from name you would like to show up in the email (eg: DA Publishing)

Once onboarded, your custom API should support the following payload format

sample (json)

{
  "personalizations": [
    {
      "to": [
        { "email": "approver1@example.com" }, //provided by the plugin
        { "email": "approver2@example.com" }. //provided by the plugin
      ],
      "cc": [
        { "email": "cc1@example.com" } //provided by the plugin
      ],
      "subject": "Subject line"
    }
  ],
  "from": {
    "email": "noreply@example.com",
    "name": "DA Publishing"
  },
  "content": [
    {
      "type": "text/html",
      "value": "<html>...</html>" //provided by the plugin
    }
  ]
}

Step 2: Configure your Experience Workspace site

Once onboarded, configure your site's Experience Workspace config sheet to enable the plugin, app, and workflow rules. Open your config sheet at https://da.live/config#/<org>/<site> and make the following changes. You need config write permissions in order to do this.

library tab — Request Publish plugin

On the library tab, add the plugin to the Experience Workspace library so authors can access it from the editing interface:

`title`	`path`	`icon`	`experience`
`Request Publish`	`https://main--aem-apps--adobe-rnd.aem.live/tools/plugins/request-for-publish/request-for-publish.html`	`https://main--aem-apps--adobe-rnd.aem.live/tools/plugins/request-for-publish/request-for-publish.svg`	`fullsize-dialog`

apps tab — Publish Requests inbox

On the apps tab, add the inbox app to the Experience Workspace Apps menu. The app automatically shows the appropriate view based on who is logged in. Approvers see pending requests to manage and authors see their own submitted requests.

`title`	`description`	`path`
`Publish Requests Inbox`	`Manage Requests to publish the content`	`/app/adobe-rnd/aem-apps/tools/apps/publish-requests-inbox/publish-requests-inbox`

publish-workflow-config tab

Create a publish-workflow-config tab and use it to define path-based rules that determine which approvers are assigned to different areas of your site. Each rule has a pattern column (which supports wildcards), an approvers column (comma-separated emails or distribution list names), and an optional cc column. The most specific matching rule is used for any given content path.

`pattern`	`approvers`	`CC`	`notifyonreject`
`/blog/authors/*`	`editor@example.com`	`leads@example.com`	`true`
`/blog/*`	`dl-reviewers@example.com`
`/*`	`default-approver@example.com`

Pattern specificity is determined by the number of path segments that match. An exact match takes highest priority, followed by closer wildcard matches, with the root /* wildcard as the catch-all fallback.

publish-workflow-groups-to-email tab (optional)

If you use distribution list (DL) names in the approvers or cc columns, add this tab to map them to individual email addresses:

`group`	`email`
`dl-reviewers@example.com`	`reviewer1@example.com, reviewer2@example.com`
`leads@example.com`	`lead1@example.com`

The config is read from the site-level config first (/config/<org>/<site>/), with an automatic fallback to the org-level config (/config/<org>/) if not found at the site level.

publish-workflow-settings tab (optional)

Add the publish-workflow-settings tab to control optional workflow behavior with key-value pairs. Add a row for each setting:

`key`	`value`	Description
`request.comments.required`	`true or false`	When `true`, the `description` field ("Please provide a description of your website content changes...") becomes mandatory. Default: `false`.
`request.comments.length`	`number`	Minimum character length for the description when comments are required. Fallback: `10` if missing or invalid.
`approvals.cc.can-approve`	`true or false`	When `true`, `cc` recipients can view and approve requests (same rights as `approvers`). Default: `false` i.e. only `approvers` can approve.

Example:

`key`	`value`
`request.comments.required`	`true`
`request.comments.length`	`50`
`approvals.cc.can-approve`	`true`

Access to the publish-workflow-requests sheet

All authors must have write access to /{org}/{site}/.da/publish-workflow-requests.json for the Request Publish workflow to work. The plugin reads this sheet to check for existing pending requests and writes new entries when authors submit.

Configure this in the Experience Workspace config at /config/{org}/ (or /config/{org}/{site}/ if using site-level config). Grant the IMS group that contains your authors write access to /{org}/{site}/.da/publish-workflow-requests.json sheet. Without this permission, authors cannot submit publish requests.

Step 3: Configure user permissions in Edge Delivery Services

Users must have the appropriate Edge Delivery Service permissions for their role on the <org>/<site>:

Authors - users who submit publish requests must have at least basic_author permissions
Approvers - users who review and approve requests must have at least basic_publish permissions

Use the AEM User Admin tool to add users and assign roles for your org and site. For a full description of available roles, see the Admin Roles documentation.

Requesting publish approval (authors)

Once the plugin is configured, authors can submit publish requests directly from the Experience Workspace editor.

Submitting a request

Open the Request Publish plugin from the Experience Workspace Prepare menu. The plugin will automatically detect your current page and load the relevant information.

The plugin pre-fills the following information:

Content Path - the page you are requesting to publish
Preview URL - a link to your draft content on the preview environment
Approvers - automatically determined from the workflow config based on your content path, with distribution lists expanded to individual names
CC Recipients - additional recipients to be copied on the notification email (if configured)

Click the View Content Diff link to see a side-by-side comparison of your draft content against the currently published version before submitting. This will open in a new tab to AEM Diff Checker Tool, you need to ensure you are logged in to sidekick to be able to view the diff between your changes and what is live. You can add a note for your approver to provide context, flag areas for review, or indicate urgency.

Click Request Publish to submit. A confirmation will appear showing who was notified. The approver will receive an email with a link to review the request.

When you click Request Publish, the plugin first refreshes the preview of your content so that when approvers receive the notification and open the preview link, they see your latest changes. The button will briefly show the request state before the confirmation appears.

Once submitted, you will receive an email when the request is approved or rejected:

Approved: Your content is published automatically, and you receive a link to the live page
Rejected: You receive the approver's reason so you can make changes and resubmit

Note: You can only have one pending request per page. If you need to make additional changes, wait for the current request to be processed first.

Tracking Your Requests

Open the Publish Requests Inbox from the Experience Workspace Apps menu to see all requests you have submitted. The app shows a My Publish Requests view listing each request with its current status.

From this view you can:

Click Preview to open the draft content on the preview environment
Click Resend Request to re-send the notification email to the approver if you haven't heard back
Click Withdraw Request to cancel a pending request if you no longer need it published

Reviewing publish requests (approvers)

Approvers open the Publish Requests Inbox from the Experience Workspace Apps menu, or follow the review link directly from a notification email. The app shows a Publish Request Inbox view listing all pending requests you are authorized to approve.

Managing requests from the inbox

Each entry in the inbox shows the content path, the author who submitted the request, and quick action buttons:

Click Diff to open a side-by-side comparison of draft versus currently published content
Click Review to open the full request detail view with approve and reject options
Click Approve & Publish to publish a single request immediately without opening the detail view
Click Approve & Publish All to bulk-publish all visible pending requests at once

Reviewing a Request in Detail

The detail view shows the content path, author, optional note, preview link, and a content diff. Use the diff to confirm the changes are correct before approving.

Click Approve & Publish to publish the content. The author will receive a confirmation email with a link to the live page.

To reject a request, expand the Reject Request section, provide a reason, and click Reject Request. The author will receive an email with your rejection reason.

Agentic mode (Assistant)

Beyond the plugin and app, the Request Publish workflow can be driven conversationally in Experience Workspace Assistant. Authors and approvers describe what they want in natural language, for example "request publish approval for this page", "what's awaiting my approval?", or "approve the homepage." The assistant runs the same workflows that app users, resolving approvers and sending the same email notifications, acting only as the signed-in user.

The assistant is powered by two features you enable per site through the Skills Editor:

The AEM Agentic Plugins MCP connector: gives the assistant the tools to request, list, approve, reject, and withdraw publish requests, backed by the same worker as the plugin and app
The request-publish skill: the instructions that tell the assistant how and when to use those tools safely (confirm before every change, preview before requesting, act only as the current user)

Step 1: Open the Skills Editor

Open the Skills Editor for your site at https://da.live/apps/skills#/<org>/<site>. You need config-write access to your site to make changes here.

Step 2: Register the MCP connector

On the MCPs tab, click + Register MCP and enter the following values:

Field	Value
`Key`	`aem-agentic-plugins`
`URL`	`https://aem-agentic-plugins.adobeaem.workers.dev/mcp`

The connector exposes the request-publish related tools: request_publish, approve_request, reject_request, withdraw_request, list_pending_requests, get_approvers_for_path, and get_publish_workflow_config.

The MCP endpoint is hosted on a trusted Adobe domain so the assistant forwards your IMS identity to it. The worker derives who you are from your signed-in session. The assistant never sends an email address or acts as anyone but you.

Step 3: Add the request-publish skill

Open the skill file Request Publish — SKILL.md and copy its full contents.
On the Skills tab, click + New Skill.
Set the skill id to request-publish and paste the copied SKILL.md into the body.
Save. Make sure the skill's status is not left as draft.

Step 4: Use it in the assistant

Open the assistant in the Experience Workspace with the page you want to work on, then try:

Authors: "Request publish approval for this page" - the assistant previews the page, shows the resolved approvers and CC, and asks you to confirm before submitting.
Authors: "What have I submitted?" - lists your own pending requests to resend or withdraw.
Approvers: "What's awaiting my approval?" - lists the requests you can approve, with preview and diff links.
Approvers: "Approve the homepage" - the assistant shows the diff, publishes on your confirmation, and emails the author.

What the assistant will and won't do

Confirms every change. It shows a summary (page, approvers, CC, comment) and waits for your explicit confirmation before submitting, approving, rejecting, withdrawing, or publishing. Blanket "approve everything" instructions are refused.
Acts only as you. It cannot request, approve, reject, or withdraw on someone else's behalf; every action is scoped to your signed-in identity.
Previews before requesting. It previews the exact page before submitting a publish request.
Reports honestly. It only reports an action as done when the underlying tool call actually succeeds.

Troubleshooting

"No approver rule found matching path"

The content path does not match any rule in the publish-workflow-config tab. Add a matching pattern (e.g., /* as a catch-all) or contact your site administrator.

"Publish workflow configuration not found"

The publish-workflow-config tab is missing from the Experience Workspace config at both the site and org level. Verify that the tab exists and is named exactly publish-workflow-config.

"Request Pending" shown instead of the plugin form

You already have a pending request for this page. Open the Publish Requests Inbox App to view its status, resend the notification, or withdraw it.

"Could not determine your email"

Your session may have expired. Refresh the page or sign in again.

"Not Authorized" shown in the approver inbox

You are not configured as an approver for this content path. The message will show who is authorized. Contact your site administrator if you believe this is incorrect.

If the app shows a 403 error

Sign out from both the sidekick and Experience Workspace, then sign in again. If the issue persists, try in a fresh private tab.

"One or more approver or CC email domains are not allowed for this org"

An approver or CC recipient email address uses a domain that is not on the allowed list for your org. Contact your Adobe contact to add the domain to your registration, or update your workflow config to use addresses from an allowed domain.

"One or more recipient email domains are not allowed for this org"

The author's email domain is not on the allowed list for your org. Contact your Adobe contact to add the domain to your registration.