Skip to main content



Coupa Success Portal

Buyer Action Workload Distribution and Filtering Notifications

Standard system functionality is that any requisitions that require buyer action are routed to all users with Buyer role.  Buyer will see those notifications under To Do's and also in their email.  Customers in larger organizations need to segregate these notifications between their buyers to avoid multiple buyers working on same requisitions.   Below are best practices to help with this.

1.  Use account security groups to restrict access to transactions between buyers.  Buyers will only get notifications for those transactions billed to accounting codes available under their account security groups.   EX.  company has COAs in US and Europe.   You need to restrict access to buyer action notifications between US and Europe buyers.  You would restrict buyers to appropriate COAs under their user settings to set up this restriction.  You can also set up these account security groups to filter access by segments (cost centers, GL, etc.)

2.  Buyers turn off their notifications and create data views under Requests tab with conditions for types of Buyer Action reqs they need to review.  They then work off these views on daily basis to take action on buyer action requests.  These views can be based on suppliers, commodities, account codes, any other fields on requests.  Some examples of what customers have done have been assigning a buyer to a commodity on a commodity object and then passing that buyer name to requisition.   Buyers can then create their views based on their name populated on the requisition resulting from commodity that user is ordering.  Same thing could be done on supplier object if you have buyer responsibilities split up by supplier.

3.  Turn off global Buyer Action setting under Company Information for non-contract spend and instead create approval workflow routing where Buyer is inserted as an approver.  Specific conditions when Buyer should be added as approver would be defined via approval chains.  This can be done dynamically off account code or commodity value or separate chains can be created based on a condition.  The benefit is that you are able to create routing rules for when appropriate Buyer should be notified and manage requisition.  But in case where requisition needs collaboration or transfer to another buyer that would not be as easily done as with general buyer action pool since requisition is in 'Pending Approval' state with a specific user rather than 'Buyer Action' where any Buyer role can access.  Delegation or adding another buyer to approval flow would be possible solutions for such scenario.  Another consideration is that if it is a free-form requisition not on contract then Buyer is not able to assign an existing contract as they are able to do in 'Buyer Action' step.  Only option to associate to an existing contract would be via adding a contracted catalog item to requisition.  Otherwise requisition is processed as non-contract backed purchase.

  • Was this article helpful?