Kzak
Junior Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Цитата:| Beta же без возможности обновления на Final |
Не заметил...
Цитата: я потыкал демо...
не совсем понял что дает реквест воркфлоу.
а так ГУИ для реквестеров прикольненький ) |
Точно, намного дружелюбнее стал - блок примечаний вынесли в обсуждения вверху и с фильтром, одновременная загрузка нескольких файлов, вынесенный направо блок, всякие приятные мелочи сначала заметил 
По воркфлов, на форуме такие пояснения от разрабов:
---
The main idea behind the Request Life Cycle is to track the life path (status) of the request. Actions configured under the Request Life Cycle are triggered upon request status change.
In our subsequent phases, we are working on workflow automation and it will be much more than this. We are always planning to provide the best to our customers.
---
Will consider the work flow automation model subsequently. As mentioned by Siddik currently we are including the guided request life cycle (RLC) model. Listing some key advantages in the feature :
- RLC is a drag and drop visual builder for configuring request life cycle connecting various status of request (from creation to completion of request). A Transition denotes the path between two statuses
- Transition supports configuring Before / During / After phases denoting the movement of status from one state to another.
- Scoping of transition can be configured in Before phase by configuring Role for the transition. for eg. if request need to be moved to 'In Progress' status only by ticket owner, then this can be configured in the Role section of Before phase
- Rule in Before phase determines when the transition can be executed. for eg. If the request is allowed to be moved to 'Assigned' status only after approval, then Rule can be added in Before phase as 'Approval status' is 'Approved'
- Mandatory and optional fields can be configured in During phase allows to get relevant request data just in time. for eg. Ticket owner can be marked as mandatory for 'Assigned' status transition so that ticket can be moved to Assigned status only when ticket owner is properly assigned
- Rule and custom script in During phase is used to check validity of the transition or to negate the transition
- Script execution in After phase can be used to handle actions like external application integration based on status transition . for eg. if ticket status needs to be updated to another application, can be done through custom script in After phase
- Email notification action in After phase is used to notify relevant stake holder on status transitions. for eg. can send a notification to requester when the request is moved to Canceled status, can send a different notification to technician when a request is raised by a VIP user,..
- Since mandatory fields can be configured for transition (path), different close mandatory can be configured for different paths. for eg. resolution need to be mandatory when request is resolved and closed, while resolution need not be mandatory when request is canceled and closed.
- Technicians will be shown with transitions configured from the current status of request. for eg. if Onhold and Assigned status are configured from Open, then when technician gets into details page can see only Onhold and Assigned status and cannot move directly to Resolved or Closed status.
RLC for a request template is optional and if needed can continue to work in existing model itself.
|
Всего записей: 32 | Зарегистр. 11-02-2015 | Отправлено: 16:25 20-11-2018 | Исправлено: Kzak, 16:26 20-11-2018 |
|
