Site Search
 

iServer Workflow

You are watching:

iServer Workflow

Watch the video introducing the new Workflow capabilities of iServer 2017

Paused

You just watched:

iServer Workflow

Watch Again
Share This

Rate this videoSaved. Thanks for your feedback!

Please Login to rate

More from this series ...

{{currentPage}}/{{totalPages}}

Previous

Next

iServer Workflow

iServer Workflow is a full-featured workflow system used to trigger notifications, perform system actions and manage content approval in iServer. This feature essentially allows administrators to build workflow templates that ensure content is approved before it’s checked back into iServer, thus protecting the quality and integrity of information in the repository.

Monitor

iServer Workflow will make it possible to set up email notifications to certain users when items are copied, deleted or edited. This level of control is needed to guarantee that only sanctioned alterations take place, especially in relation to highly sensitive items.

Automate

Workflow will also feature a high degree of automation. This means that once a workflow has its rules defined and it is triggered by an action, it will closely follow a pre-set course until completion. Provided the users supply the required input when prompted, the process will reach the designed outcome without requiring human supervision.

Approve

Lastly, Workflows supports approval-based visibility, which means that no changes are ever made to the single source of truth without a final sign off by the content owner. So there is a separation between draft work and approved work, with only the latter being published to business, which minimizes the risk of accidental submissions.

Benefits

The benefits of this are significant: timely alerts when changes to repository data are registered, a more streamlined experience through approval-based visibility of repository content, as well as an overall improved content governance.

So, who might benefit from using Workflows?

Well, to safeguard the integrity of enterprise value chains, for instance, an enterprise architect may submit any changes done to their respective business unit leader for approval, and only then have them committed to the repository.

By the same token, a business analyst might want to personally sign off any changes done to the process landscape before they can be seen by the rest of the team. And lastly, a governance lead would probably find it useful to be notified if, say, a business-critical application or technology component is being checked-out, and by whom.