> For the complete documentation index, see [llms.txt](https://docs.umbraco.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.umbraco.com/umbraco-workflow/getting-started/submitting-changes.md). # Submitting Content for Approval Learn how to submit content changes for Workflow approval When requesting workflow approval for content changes, editors must provide additional information detailing the change. To submit the content changes, click the **Request publish** button in the editor footer. To submit an unpublish request, select **Request unpublish** from the **Request publish** button menu. The option is available when **Use workflow for unpublish** is enabled. {% hint style="info" %} Before Umbraco Workflow 18.2.4, unpublish requests were made by selecting the **Action** option in the request approval overlay. {% endhint %} ![Buttons](https://1513306126-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FonwuUOTAf576n6UVv16T%2Fuploads%2Fgit-blob-3cc8d7e7ad1f30cdc2b39dcb9fe1c788b7a1959c%2FButtons.png?alt=media) Both options open the request approval overlay. The overlay headline shows the requested action and the document or element name: ![Request approval overlay](https://1513306126-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FonwuUOTAf576n6UVv16T%2Fuploads%2Fgit-blob-13d4ac78e4ec2b3a8e212beba05e53352630e277%2Fapproval-request-overlay-detailed-v14.png?alt=media) Depending on the Document Type and Workflow settings, the overlay will provide inputs for: | Fields | Description | Visibility Conditions | | ------------------------ | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------- | | **Describe the changes** | A field for adding comments to describe the changes made to the content. | Always visible. | | **Attachment** | Upload media or files attachment. | Visible only when **Allow attachments** is set to true. | | **Publish on** | A date picker for scheduling the content's publishing date. | Visible only when **Allow scheduling** is set to true. Hidden for unpublish requests. | | **Unpublish on** | A date picker for scheduling the content's unpublishing date. | Visible only when **Allow scheduling** is set to true. | | **Variants** | Allows selection of language variants to publish. | Visible only for variant content. | It is possible to schedule both **Publish on** and **Unpublish on** dates in a Publish workflow. Once content has been unpublished, a new workflow process is required to republish the content. ## Variant Workflows If the document varies by culture, the editor must select one or more variants to submit for approval. When a document is invariant, the variants selector is not displayed, and the approval flow follows the [default permissions inheritance pattern](/umbraco-workflow/getting-started/workflow-workspace-view.md#approval-flow-types). ![Request approval overlay](https://1513306126-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FonwuUOTAf576n6UVv16T%2Fuploads%2Fgit-blob-627b7dd1d309c24ea120cc877a634993c39459a3%2Fapproval-request-overlay-variants-v14.png?alt=media) The editor will not be able to select variants where: * They do not have permission to edit the language, or * The variant is already in a workflow. When submitting multiple variants, a workflow process is started for each variant, using the [default permissions inheritance pattern](/umbraco-workflow/getting-started/workflow-workspace-view.md#approval-flow-types). Newly created variants are automatically assigned the configuration from the default language. Alternatively, all variants can be submitted in an invariant workflow, where they will be approved in a single workflow process. Invariant workflows use the permissions set on the default language. Editors must have permission to edit all the current node's variants to be able to initiate an invariant workflow. The invariant workflow will publish all variants, regardless of their node state, that are not already in workflows. This means that previously unpublished variants will be republished when using invariant workflows. In most cases, it is preferable to select the individual variants. ## Content Validation and Pending Changes When submitting for approval, Workflow will automatically save variants with pending changes. Validation errors are reported in the UI using Umbraco's validation messages. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.umbraco.com/umbraco-workflow/getting-started/submitting-changes.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.