EBP Shopping Cart goes to all users when SLAPPROVER value is bad

[Soady, Phil]

I take it spamming the CEO and MGT didn't go down well ;-)
 
Before Jos can  get on the pony, the option of not having the task
as general but assigned to certain roles,  to avoid sending to all
should be considered. Don't use general task.
 
This still may be 90% of employees depending on the roles.
 
You can  write your own "RULE/ROLE" whatever they called depending on your
version of SAP.
 
Your custom  "RULE" is of type function that could call the original role/rule
via function CALL FUNCTION 'RH_GET_ACTORS' and if nothing is returned set the result
ACTOR to an ADMIN position or user etc.
In other words if you don't  like the robustness or behaviour
of a rule, you can write a wrapper.
 
 
The option with "NO" agents and error should still work.
Not sure what happened here in the this standard EBP role.
 
You can individually test RULES so you should be able to verify
your custom wraper can NEVER do a spam ALL.
 
 
 
 
-----Original Message-----
From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU] On Behalf Of Trant, David
Sent: Thursday,8 January 2004 8:01 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: EBP Shopping Cart goes to all users when SLAPPROVER value is bad
 
 
Happy New Year!
 
Twice in one week, during the holidays of course, we had an approval task and corresponding Outlook e-mail notification go to all EBP users, including naturally the executives and CEO.  We had a similar problem last summer due to a problem with the product category, and at that time implemented note 491804, EBP Shopping cart goes to all possible agents.  Our hope had been that the note would have addressed all occurrences, but clearly it does not cover problems with SLAPPROVER.  We are on EBP release 3.0.  In one case, the administrator mistyped the value of the SLAPPROVER extended attribute for someone in the GUI transaction PPOCA_BBP.  In the second occurrence, someone left the company and the administrator changed the SLAPPROVER value at a high level in the hierarchy, but did not realize that one particular user within that organization for some reason had her own SLAPPROVER value rather than inheriting it from the higher level.  In both examples, agent determination failed!
, and therefore the task went to all possible agents, which meant everyone since it's a general task.
 
Is anyone aware of a note other than 491804 to address this issue?  Also, does anyone know whether future EBP releases might add more robustness to either the SLAPPROVER/user maintenance process, or further address the issue of agent determination failures with general tasks?  Some attributes have search helps and consistency checks (indeed, sometimes you must use the search help in order to associate the correct GUID), but in 3.0 SLAPPROVER has neither.  Our administrator has remarked that it is possible to type one name in the browser user maintenance transaction and another in the GUI org structure maintenance.
 
Just an editorial comment:  my management has stated repeatedly that under no circumstances do they ever want a task going to all users.  They understand the idea of sending tasks to all possible agents upon agent determination failure, but do not believe that should extend to general tasks.  I'm aware of the checkbox on role/rule definitions to err out when agent determination fails, but this doesn't cover all scenarios.  I'd be happy to hear of anyone else's ideas on preventing these mass task deliveries at a global level.
 
Thanks,
David
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]