Hi Carolyn,<br><br>Good to hear. Could you tell me though, how are the agents determined in these steps?<br><br>Regards<br>Rick<br><br>On Wednesday, October 30, 2013, Carolyn A Fuller <<a href="mailto:fuller@mit.edu">fuller@mit.edu</a>> wrote:<br>
> Mike,<br>><br>> I have discovered it is only a problem in our development environment.<br>><br>> I tried to replicate the issue in the EHP7 staging environment that we would open to SAP and I couldn't reproduce it. The workflow successfully showed up in the new approver's inbox after I ran SWU_OBUF.<br>
><br>> So I need to explore with our Basis team what the differences are between our staging and development environments.<br>><br>> Thank you everyone for your help. I have learned a lot.<br>><br>> Carolyn<br>
><br>> On Oct 29, 2013, at 1:50 PM, Mike Pokraka <<a href="mailto:wug@workflowconnections.com">wug@workflowconnections.com</a>><br>> wrote:<br>><br>>> Hi Carolyn,<br>>><br>>> If you can reliably reproduce it then I would suggest it needs to be<br>
>> logged with SAP. I'd be interested in the outcome.<br>>><br>>> Regards,<br>>> Mike<br>>><br>>><br>>> On Tue, October 29, 2013 3:27 pm, Carolyn A Fuller wrote:<br>>>> Rick,<br>
>>><br>>>> In the email below I meant to say I ran SWI5 not SWIA after SWU_OBUF. So<br>>>> the answer to your question is no, the work items were not appearing in<br>>>> the new approvers inbox until after I ran SWI1_RULE for each work item.<br>
>>><br>>>> We just upgraded this environment to EHP7 from EHP6.<br>>>><br>>>> In EHP6, I can do the following successfully:<br>>>><br>>>> 1- Add new approver to an inbox<br>
>>> 2- Run SWU_OBUF<br>>>> 3- Immediately create a transaction that triggers workflow that goes into<br>>>> the inbox in question<br>>>> 4- It is in the new approver's inbox<br>>>><br>
>>> In EHP6, I follow the first 3 steps above but the workflow item it is not<br>>>> in the new approver's inbox until I run SWI1_RULE on the workflow item.<br>>>><br>>>> Carolyn<br>
>>><br>>>> On Oct 29, 2013, at 9:09 AM, Rick Bakker<br>>>> <<a href="mailto:rbakker@gmail.com">rbakker@gmail.com</a><mailto:<a href="mailto:rbakker@gmail.com">rbakker@gmail.com</a>>> wrote:<br>
>>><br>>>> Hi Carolyn,<br>>>><br>>>> Your situation sounds very wrong. What sort of inbox are the users using?<br>>>> Is it a case of the UWL not being refreshed?<br>>>><br>
>>> If you look in SWI5, is the work item being assigned to the user<br>>>> immediately?<br>>>><br>>>> Regards<br>>>> Rick Bakker<br>>>><br>>>> On Tuesday, October 29, 2013, Carolyn A Fuller<br>
>>> <<a href="mailto:fuller@mit.edu">fuller@mit.edu</a><mailto:<a href="mailto:fuller@mit.edu">fuller@mit.edu</a>>> wrote:<br>>>>> Mile,<br>>>>><br>>>>> When we first noticed this behavior, one of the other workflow<br>
>>>> administrators set up 2 test IDs as approvers and ran SWU_OBUF. The<br>>>>> tester who owned those 2 test IDs went back to her desk and 45 minutes<br>>>>> later she created a transaction under one ID that triggered the workflow<br>
>>>> that should have appeared in the inbox of the other ID. It did not.<br>>>>> Several hours later she created an identical transaction which triggered<br>>>>> the same workflow and it did appear in the inbox of her second ID.<br>
>>>><br>>>>> Last night after I set up another approver in that inbox, ran SWU_OBUF<br>>>>> and SWIA, the new approver had all the workflows from April in his inbox<br>>>>> but none of the workflows that were created yesterday. It was not until<br>
>>>> I had run SWI1_RULE on each of the workflows created yesterday that they<br>>>>> appeared in his inbox.<br>>>>><br>>>>> This upgrade is the first time we are noticing this behavior. Before the<br>
>>>> 2012 upgrade I never got any complaints. This past year, after the 2012<br>>>>> upgrade, I got possibly 3 complaints that workflows were not appearing<br>>>>> in a new approver's inbox but these workflows were from transactions<br>
>>>> created prior to the person being set up as an approver. Since we have<br>>>>> more than 1 approver per position, it was easy to dismiss these 3<br>>>>> complaints.<br>>>>><br>
>>>> This behavior from the 2013 upgrade, will not so easily be dismissed. I<br>>>>> don't know whether our MIT community will tolerate being asked to send a<br>>>>> list of each missing transaction so that we can run SWI1_RULE against<br>
>>>> them. By the way, we have to have a list of transactions because of the<br>>>>> multiple people per position. We have no positions with no active<br>>>>> agents.<br>>>>><br>
>>>> Carolyn<br>>>>><br>>>>> On Oct 29, 2013, at 6:05 AM, "Mike Pokraka"<br>>>>> <<a href="mailto:wug@workflowconnections.com">wug@workflowconnections.com</a><mailto:<a href="mailto:wug@workflowconnections.com">wug@workflowconnections.com</a>>> wrote:<br>
>>>><br>>>>>> Hi Carolyn,<br>>>>>><br>>>>>> It could also be the testing method. One gotcha is if you use multiple<br>>>>>> sessions and stay in the same transaction.<br>
>>