Insights & updates from our experts
When a request (or problem) is related to a workflow, the assignment is automatically set to the manager of that workflow. This makes sense in many cases, but in other cases, for example where the request was already assigned and the workflow manager is not involved in resolving it, it can be preferred to keep the assignment with the current team or member. The new setting ‘Assign related requests and problems to workflow manager’ on the Workflow Template form makes this possible.

This new setting is checked by default. When it is unchecked, requests and problems that are related to a workflow based on that workflow template are not automatically assigned to the workflow manager.
Consequently, a request or problem is now allowed to be set to status ‘Workflow Pending’ when the member is still empty. This entails that the request or problem cannot be auto-completed when the related workflow is completed. Instead, the request/problem is then set back to ‘Assigned’.

An AI SRE that knows your incidents
Most AI SREs are pattern matchers trained on public data. They know what a memory leak looks like in the abstract. They don't know that your payments-api has a flaky liveness probe everyone ignores, that the checkout team owns the retry policy, or that the last three "database incidents" were actually cache misconfigurations. That knowledge lives in your postmortems, your Slack channels, and the heads of two senior engineers.

How Long Should ITSM Implementation Really Take in 2026?
Most vendors will tell you ITSM implementation takes six months to a year — but modern, configuration-first platforms have rewritten the math entirely. See what real implementations look like in 2026, and why a long rollout is now a choice, not a given.















.webp)
.webp)

.webp)












