How do I set a process / document ect. to the status "Expired" and why is this sometimes not possible?

Want to set a released process, document or item to Expired?

Step 1:

You open the status dialog and go to the point "Change status" and here under the point "Status" you select "Request to Expire".

Please make sure that all necessary parameters are filled in, otherwise the workflow cannot be started.

Step 2:

Now a task is triggered for the persons entered under Quality Manager (if applicable) and Responsible. This task can be found in the taskbar or in the taskboard under "my tasks". In addition, an email is triggered to inform the releaser.

Step 3:

The respective releaser approves or rejects the request.

The author will be informed by email about the respective actions of the releasers. When all releasers have approved, the status changes to "Expired". Until this point, the status remains on "Released" or "Released and Valid".

If the request is rejected at one point, the workflow is terminated at this point.

Please note that the release task is sent to all listed releasers (QM, Responsible) at the same time. And there is a difference between "Request to Expire" and other releases: If the Responsible approves the "Request to Expire" before the other releasers, then the workflow is closed. In this case, the Responsible has priority over all other approvers.

As the tasks of the other approvers then remain on "To Do", we recommend that the approvers still approve the task, even if it no longer has any effect. In this way, the tasks are maintained on the task board.

Why is there no "Request to Expire" in the "Change status" dialog ?

You want to set a released element to Expired, you have filled in all relevant parameters, but you can't find the "Request to Expire" in the "Change Status" dialog?

Then you should take a look at the lifecycle diagram.

Here you can see very well what has already happened in the currently selected process version and where the process (or document / element) currently stands.

Problem 1:

The "Request to Expire" has been made, the releasers have been informed and the process is still in the released status.

The first releaser has approved the case, the second releaser is still pending.

This is where the highest "risk potential" lies:

If one of the releasers does not release the process (o.a.), the process remains stuck at this point in the workflow, usually without being noticed. This happens especially often if there is more than one releaser, since all registered releasers (QM & responsible) have to release the request.

Solution:

The author should ideally monitor the processes that he wants to set to "Expired" and watch for the returns of approvals (or rejections) via email.

In parallel, the lifecycle diagram can be reviewed to determine if all release steps have been met.

The author reminds the releaser of the task that is still open. If the releaser is currently unavailable and the release is urgent, the admin can assign the task to another appropriate person under "all tasks" who will then release the request.

Problem 2:

If the "Request to Expire" is not visible in the status dialog, it is also possible that one of the people involved has left the company in the meantime and the user has been deactivated. Ideally, in such a case, all processes / documents (etc.) associated with the user should have been assigned to a new user.

If this has not been done, the workflow will be stuck here as well.

Whether a user has been deactivated or not can easily be seen in the Detail Content of the process (o.a.) or in the Change Status dialog:

Next to the user name you can see a small "i". Clicking on this will show the permissions as well as a possible deactivation of the user.

Solution:

To exchange the corresponding participant, an architect or admin can open the version dialog and then "Change Attributes" and exchange the corresponding user for a new one here.

Afterwards, the corresponding element must be clicked on again in the lifecycle diagram and then the user can be reassigned by the architect / admin in the detail content and thus the task can be triggered again.

If everything was handled well, the lifecycle diagram looks like this at the end and the process (above) is in the "Expired" status