Case goes to robot queue but NOT into workbasket
I have a robot queue added to a flow and in the Advanced properties, I set the status as 'Pending-Automation'. When a case is created, and reaches the shape, the case status is updated to 'Pendng-Automation' but when I check the workbasket in the console portal, it says there are 0 items in queue. Any ideas?
Pegasystems Inc.
US
Assuming you have the flow action set to assign the case to a Robot Queue (and you have specified the workbasket), then it should appear there. You might post screenshots of your flow action as well, so we can see if it is correct.
Health First
US
Hello,
I have attached a screenshot of the flow. This is the very beginning of the flow and the first thing it should do is go straight to the workbasket. Thanks.
UPDATE 07102018: Is anyone familiar with privileges? I have a feeling that may have to do with the case getting stuck right before being put into the workbasket. Also sasnt, I had another app that did not utilize a flow action but the cases were still sent to the workbasket. So the application I'm trying to implement the robotics on also does not have a flow action rule calling the automation.
Health First
US
Another thing to note is that cases are added to the robot workbasket in another application but not in this one. We thought it might have to do with the operator ID and access group. When registering our VM robot's operator ID to the application, we would remove it in the other. More details:
-The workbasket's capacity has been set to hold more than enough cases
-Copied the other operator ID of the working application to the target app and renamed it
-The operator ID was set as manager and the manager ID was set under Authorized Managers
-Created separate access group for operator ID that registers robots and robot operator IDs apart from the default [App]:Administrators
-Verified all available roles & portals for the target operator ID is synonymous to the working operator ID
-pyGetAccessGroupForRobotWorkGroup decision table was originally in FW ruleset. It was then moved to implementation layer. The else result also contains a default access group (which is the same as the one we want cases to go in anyway)
Another thing to note is that cases are added to the robot workbasket in another application but not in this one. We thought it might have to do with the operator ID and access group. When registering our VM robot's operator ID to the application, we would remove it in the other. More details:
-The workbasket's capacity has been set to hold more than enough cases
-Copied the other operator ID of the working application to the target app and renamed it
-The operator ID was set as manager and the manager ID was set under Authorized Managers
-Created separate access group for operator ID that registers robots and robot operator IDs apart from the default [App]:Administrators
-Verified all available roles & portals for the target operator ID is synonymous to the working operator ID
-pyGetAccessGroupForRobotWorkGroup decision table was originally in FW ruleset. It was then moved to implementation layer. The else result also contains a default access group (which is the same as the one we want cases to go in anyway)
On the OpenSpan side,
For some odd reason, the operator ID in charge of registering robots (which was created in the other application) is able to log on to both applications, even though it only has one of the access groups/targeted for the other application. When trying to use the operator ID of the target application, the runtime instantly shuts down upon logging in/boot. This is unexpected because the operator ID in charge of registering robots should not be able to log on to the target application, only the operator ID created in the target application.
Does anyone know why this is happening and have any suggestions?
Pegasystems Inc.
US
Without gaining access to your system, I am at a loss for what your issue might be. I would suggest that you open an SR to have support take a look. If you do open an SR, please notate the number here for tracking purposes.
Accepted Solution
Health First
US
You must override the GetNextWork activity and force the operator ID to be that of the robot's as well as circumstance the rule to know that its of type robot.