If I have a sceanrio where a customer wants to use Aware to manage interaction with different 'Contact Sets' how could I go about doing this.
e.g.
Users have been told that they will be dealing with Company 'A' anmd their records (clients) today (call centre type environment). When they log on they see only those customers (all other functionality is the same in terms of interaction types).
On the next day the same user may be told they are dealing with Company 'B' and their records (clients). When they log on they see only those customers (all other functionality remains the same).
It is some form of filtering and even if the user had to select from a drop down as they logged on to identify which filtered contact set they are working on then that would be fine.
Multiple Contact Sets
-
- Posts: 595
- Joined: Sun Apr 24, 2005 2:22 am
- Contact:
The most straightforward approach would be the one that closely follows your description. You can define an object ContactSet with attributes Companies and Employees to allow one or more employees to work on a list of selected companies. Create access level 'Manager' and allow users of that access level to create/modify ContactSet instances at run time to assign employees to companies. Create access level 'Employee' for employees (not allowed to change ContactSet). Add the following protection rule to object ContactSet:
If LoggedInSystemUser.AccessLevel = 'Employee' AND NOT (LoggedInSystemUser IN ContactSet.AssignedEmployees)
Then READ PROTECT ContactSet FROM Employee
Add a query to display all ContactSet instances and allow Employee users to run it. At run time the system will automatically filter out ContactSet instances from the displayed results based on the above rule. Note that the rule will not affect the ability of other access levels (such as Manager) to see all ContactSet instances if they run the same query.
If you find it more convenient, you can simplify this design by eliminating the object ContactSet and making the list of assigned employees an attribute of object Company (and only allow Manager to change the attribute). The protection rule would then look like this:
If LoggedInSystemUser.AccessLevel = 'Employee' AND NOT (LoggedInSystemUser IN Company.AssignedEmployees)
Then READ PROTECT Company FROM Employee
The query would then display all Company instances. By running this query the employee user would see only those companies to which the user is assigned.
Let me know if either of these solutions is acceptable or if you need more details.
If LoggedInSystemUser.AccessLevel = 'Employee' AND NOT (LoggedInSystemUser IN ContactSet.AssignedEmployees)
Then READ PROTECT ContactSet FROM Employee
Add a query to display all ContactSet instances and allow Employee users to run it. At run time the system will automatically filter out ContactSet instances from the displayed results based on the above rule. Note that the rule will not affect the ability of other access levels (such as Manager) to see all ContactSet instances if they run the same query.
If you find it more convenient, you can simplify this design by eliminating the object ContactSet and making the list of assigned employees an attribute of object Company (and only allow Manager to change the attribute). The protection rule would then look like this:
If LoggedInSystemUser.AccessLevel = 'Employee' AND NOT (LoggedInSystemUser IN Company.AssignedEmployees)
Then READ PROTECT Company FROM Employee
The query would then display all Company instances. By running this query the employee user would see only those companies to which the user is assigned.
Let me know if either of these solutions is acceptable or if you need more details.
Aware IM Support Team