Automated Workflow and Auto Tasks
With automated workflow and auto tasks, you can customize Quest® Stat® to enforce your own particular business practices. In Stat, workflow rules determine a set of conditions that must be met before a Change/Service Request (CSR) can move to the next stage in its development life cycle. Stat features an interactive workflow tool that allows you to define these rules graphically, which you then save as a template. Workflow templates apply to specific combinations of service domains and CSR Types.
You can also configure Stat to generate auto tasks triggered by system events. Auto tasks automatically assign work to users, sometimes multiple users. For example, once a change request is approved, Stat can be configured to generate auto tasks for development and testing teams. Auto tasks reduce the time it takes to complete repetitive tasks always associated with certain jobs.
All time spent on auto tasks (as well as user-defined tasks, which are manually added to CSRs) can be tracked together in a CSR or project. The status of all tasks can be viewed on-line at any time.
For more information on workflows and auto tasks, see Chapter 3, “Change/Service Requests,” and Chapter 5, “Tasks and Time Entries.”
Information Management
Quest® Stat® is an excellent tool for tracking, resolving and documenting reported issues. You can use Stat as your primary help desk application, or integrate it seamlessly with an existing enterprise help desk tool. After receiving an email request from a user, non-user, or another help desk application, Stat can open a Change/Service Request (CSR) and route it to the appropriate queue or individual based on business rules that you define. Throughout the life cycle of a request or issue, Stat serves as the knowledge repository for your documentation, which in turn assists other users who may experience similar problems in the future.
To further decrease the amount of non-productive time spent on a request or issue, you can configure Stat to automatically communicate with customers when their service requests are updated or resolved.
Stat Security
System administrators control Quest® Stat® security on two levels. At the first level, users are assigned to user classes. A user class is a grouping of rights that controls what members of that class can do and what fields and data they can see. User class rights control most of the functionality in Stat, including the ability to run various wizards, edit Change/Service Requests (CSRs), define new users, and open projects.
At the second level, users can be assigned to different user classes for each service domain. For every service domain, a user can have the security rights of one or more user classes or even be given no access whatsoever. This prevents users from performing actions or seeing data in an area of the business that does not pertain to them. The following table shows how a user’s security might be defined.
In this example, the user is assigned to the Developer user class in the Change Control service domain, which lets the user edit and create CSRs, lock objects, and create archive sets. However, the user cannot edit maintenance tables, add new users, or migrate archive sets. In the Information Systems service domain, the user is assigned to two user classes: Staff and Projects. The Staff user class gives the user very limited access to the service domain; it only lets users create new CSRs and view existing CSRs. The Projects user class, however, lets users create and edit projects in the service domain. Finally, in the Human Resources service domain, the user has no access.
The indication of primary in the Change Control domain means that when Stat prompts the user to select a service domain (for example, when opening a new CSR), the default choice is Change Control.
For more detailed information, see the Stat System Administration Guide, Chapter 3, “Stat Security.”
Connecting to Stat
