Generic Enterprise Workflow Requirements – Matrix
December 6, 2010
Integrate with single sign-on solution roles as currently used
|
Generic Enterprise Workflow Requirements – Matrix |
|||
|
Description |
Employee review |
Online Availability |
Recruiting |
| Workflow Core | |||
| Manage and support various Event types | |||
| Create, Update or Delete a token | X | X | |
| Status Changes | X | X | X |
| Approval Activities | X | X | X |
| eSignatures (statements of certification, recognition of review or receipt, etc) | X | X | |
| Legal statements of acceptance of contract | X | ||
| Batch Process | X | ||
| Handle Triggers | |||
| Scheduled | X | X | X |
| Time based intervals | X | X | X |
| Manually launched | X | ||
| Launch another workflow and or be launched by another workflow | X | X | |
| Routing Options | |||
| Parallel paths | X | ||
| Conditional | X | X | X |
| Ad-Hoc | X | X | |
| Business Rules | |||
| High Level of Complexity | X | X | |
| Ability to specify business rules at the token type, ORG, Role, User, metadata element, time period (or any combination of above rules) etc. | X | X | |
| Control over views of workflow elements | X | ||
| Allow for ad-hoc modifications to business rules with defined security access | X | ||
| Ability to add business rules for a new token types or ORG/Role/User etc without code changes | X | ||
| Ability to define escalation route(s), triggers or events for a specific token type or attribute. | X | X | |
| Notifications | |||
| Messages could be sent via email, RSS feed, digest of many messages, text message, or other means | X | X | X |
| Automatically notify individuals of tasks that they must perform. | X | X | Xd> |
| Automatically notify the creator of the token when task completion or outcome occurs | X | X | |
| Support time based triggered notification. | X | X | X |
| Record when system messages are sent and retain copies of sent messages. | X | X | X |
| Fetch data (any/all data sources) and include it in a notification message. | X | X | X |
| Audit & History Tracking | |||
| When a token is passed through the workflow each status and activity change should allow for user comments. | X | X | |
| Record the ID of the person or system who performs any activity in the system, as well as when and where the activity takes place (within what application or what portal, etc). | X | X | X |
| Display a record of all the statuses a token goes through, and date the token changes status. | X | X | X |
| Maintain and display a snapshot or version of th token at key routing points within the workflow. | X | ||
| Audit and history trail should include notification information | X | X | |
| Presentation Layer | |||
| Different portals for the different defined roles | X | ||
| Option for publishing or read-only views to public | X | ||
| End-user applications may require their own separate presentation layer within their application. | X | ||
| Information about the state of each token in the workflow is easily accessible. | X | X | X |
| List of tokens and their metadata that allow for sorting and filtering. | X | X | X |
| Profile of users or roles to allow for view definitions. | X | X | X |
| Graphical representation of workflow process and progress. | X | ||
| Provide color-coding options for activities, status and flow as required for escalation and critical paths, etc. | X | ||
| Allow for control of notification preferences through the presentation layer (rather than through the workflow configuration). | X | ||
| Expose audit and history trail of the token | X | X | X |
| Document Management | |||
| Versioning and source control of the all tokens and their associated attachments. | X | X | X |
| Attachments of various file types, supplements, etc. | X | X | |
| Support configurable retention, encryption, confidentiality and document/file destruction | X | X | |
| Security | Integrate with single sign-on solution roles as currently used. | ||