# Default configuration definitions

## Definitions

### What is Workflow States?

The status of the article is described by "pubStatus". Each workflow normally is given a name that represent the state. The workflow itself describe the Pubstatus and to what state or other states (nextStates) the article can transition to. The transition can be controlled by certain preconditions that may be present.

![Schematic Workflow State ](/files/-LqeadyWaiR66BM_xXmc)

To understand that the Workflow has a name that corresponds to a pubStatus is an important step on the way of understanding the configuration. The publish flow can be configured with any pubStatus. Here are some common workflow states in the publish flow.

![Common Workflow state and their config name ](/files/-LqebIBMNaEHpJpXnWTZ)

{% hint style="info" %}
If the status reflect an IPTC- standard it has a name as “**stat:xxx**” and if it is a customized status it is has a name of “**imext:xxx**”.

DRAFT is "imext:draft"

APPROVAL is "imext:done"

SCHEDULE is "stat:withhold"

PUBLISH is “stat:usable”

REPUBLISH is “stat:usable”

PUBLISHCHANGES is “stat:usable”

UNPUBLISH is “stat:canceled”

This means that the IPTC-names represent the standardized definition, whereas the the other are customizations.
{% endhint %}

### Transitions - the path to nextState

This is what or which states that the article can transition to. It is described with “nextState” in the configuration. The transitions are controlled with preconditions. See the figure from above again:

![](/files/-LqeadyWaiR66BM_xXmc)

Example of transistion in code:

```
            "transitions": [
                {
                    "nextState": "publishchanges",
                    "title": "Publish changes",
                    "preCondition": {
                        "hasPublishedVersion": true
                    }
                },
                {
                    "nextState": "republish",
                    "title": "Republish article",
                    "preCondition": {
                        "hasPublishedVersion": true
                    }
                },
                {
                    "nextState": "cancel",
                    "title": "Unpublish",
                    "preCondition": {
                        "hasPublishedVersion": true
                    }
                },
                {
                    "nextState": "done",
                    "title": "Ready for approval"
                },
                {
                    "nextState": "publish",
                    "title": "Publish Now",
                    "preCondition": {
                        "hasPublishedVersion": false
                    }
                },
                {
                    "nextState": "withhold",
                    "title": "Scheduled publication",
                    "preCondition": {
                        "hasPublishedVersion": false
                    }
                }
            ]
```

### Priority - useful if you need a priority button

A transition state; i.e. nextState can be given a more visible primary or secondary button in the dialog by specification of priority in the configuration. With the priority specified you get the “Publish changes” button in increased sized and on top.

![](/files/-Lvewjoa9RqwFn3zgQvT)

In code this is written:

```
"priority" : "primary"
```

### Actions

Can be described as what will happen when the workflow state is entered. The actions are optional to add to the configuration. The following are available:

* pubStart
* pubStop
* pubStatus
* hasPublishedVersion (see below)

An example of actions in the configuration code:

```
"actions": [
                {
                    "pubStatus": "imext:done"
                }
            ],
```

### Published to public repository - Defining the flag hasPublishedVersion

In the configuration you use the flag hasPublishedVersion to sign that the article is in a state with a published version.

![](/files/-LqemzYUOyZuvTxSa8GZ)

To use this function the content must be stored in two separate Open Content repositories. One that stores the editorial version/versions and one that has the article version/versions that is published, i.e. editorial Open Content and public Open Content. This is fundamental for the installation and the publish flow and not an effect by the publish flow configuration, instead the environment must have these fundamental installation units to be able to be configured with the hasPublishedVersion-flag.

The article is either published or unpublished and that is set as an action in the configuration with the hasPublishedVersion flag as either true or false. This flag is then used as a precondition for other transitions to happen.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.navigaglobal.com/writer/6.2.2/admin-guide/publish-flow/default-configuration-example.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.