While xFlow receives incredible feedback for it's new approach of working within ITSM, many customers are currently following processes and rules which can not be enforced by xFlow as of now. Two customer examples for that are
1. filter referencing object attributes (example "Group Responsibilities for Ticket types"):
Customers of SDM may have extended the metamodel to assign UserGroups to specific ticket types (e.g. “group1, …., group4” will have responsibility for incidents only while “group5, ….,group10” will work on change tickets, group11 may have have responsibilities for both)
These rules are driven by process requirements and can be implemented in the classic interface . Xflow does not allow to adopt filter settings. In this case, the “transfer” of a ticket should limit the choices based on ticket type and group privileges, other “rules” could consider location or other attributes. Not just "Groups", we could think about capabilities to filter any lookup field based on more flexible filter criteria.
2. Within the CMDB relationships can define a service tree hierarchy and a ticket may refer to that.
As an example, the SAP Service consists of different service modules (SAP FI, SAP-HR and others). Once the SAP is picked, the list of sub-services (in a different ticket attribute) should be limited to the relevant list.
The capability of adding those dynamic filter options to xFlow would make it much easier to apply process rules.