Skip to Content
Personal Insights
Author's profile photo Adam Urban

Building Ariba documents approval flows with focus on purchase requisitions – do’s, don’t s and corporate practices from own experience

The possibilities how to set up purchase requisitions (PR) approvals in Ariba are manyfold. Sometimes you might wonder what are the best practices, what are the possibilities and how to satisfy your business needs. Wonder no more, I got you covered. In this article compiled from experiences of several big multinational corporations I will talk specifically about PR approvals, but the general logic how thy system works can be applied also for other types of documents – good receipts (GR), supplier data updates (SDU) for catalog uploads and many others.

Let’s start with the basics – how to access the release strategy workflow. In top right corner of your screen select “Manage” and then “Approval Processes”. Then select relevant Approvable Type. In our case it will be “Requisition”. Make sure that you are in the right realm for given Approvable Type. For purchase Requisitions it will be the child realm. You can create new or just click on the Title of existing one to adjust. When looking at specific flow already, make sure to click “edit” in top right corner so all the below mentioned options would be visible for you.

In this article we will focus on “Approval Rules” tab which defines the main flow for given document type. Approval Process Diagram shows you all the approval nodes that are set in your system por particular document approvable type. That obviously doesn’t mean that each of the nodes will be relevant for every purchase requisition. This will depend on the conditions set for given node, uploaded approval lookup table behind the node, should you decide to use it and on the PR proprieties.

You can create separate nodes also for different scenarios e.g. – create one to put RPA which should add freight to the PRs, specific nodes for freetext/ad-hoc requisitions for buyers to check the pricing and the supplier and so on.

The nodes themselves can be organized sequentially in series, meaning the document needs to pass through approval in the previous node before it can be sent for approval to the following one, or in parallel, meaning approvers in both nodes need to approve so the document would progress to the next approval step.

Let’s check following areas you can find in the UI for each approval node: Conditions and Action.


While setting up conditions, you can work with logical operators like “None Is True” or “All Are True” to define how the conditions should work together. Some of them will need to be satisfied together, for some of them only one of the cases will be enough to trigger the desired action. You can build quite complex structures of conditions with their own sub-conditions etc. You can use those logical operators to connect conditions consisting of some predefined system conditions like “Requisitions Has Supplier”, “Requisition has items without a supplier”, “Approvable Has Ad-Hoc Line Items” or so called “Field match conditions” where it is up to you to select the relevant field out of hundreds of available ones (this task can get quite tricky) and define fields’ values that will trigger the approval (for example procurement unit needs to be XY or PR amount must be greater than certain threshold).

User level maintained PR approval limit is relevant for approvals too. You can set up for example condition saying that the node will be relevant only and approval will be necessary only if the amount exceeds approval limit of the requester.


As soon as you set up the Conditions steering relevance of each created approval node, you need to decide on the action which should be performed in case the node will relevant for given PR. You have 2 options. Either you decide to “Add Approvers and Groups”, in that case you are presented with dropdown of choices about who should be added as approver with additional possibility to define which Group should be included in the approval or you opt for usage of Approver Lookup Table which gives you far more flexibility.

Approver Lookup Tables

Approver Lookup Table option obviously expects you to define content of such a table. It should be created in csv format file and you can select requisition proprieties which will be relevant for PR approval relevance assessment. You can do this by looking for relevant Field Names after clicking on “Add column”. You can then freely choose the Column header name which wil represent selected field in your csv table. For each field you can also select the Operation, in other words if the field value should be exactly the one you specify to trigger the approval, if it will be enough that the value starts wit the root you specify or if it should contain some part of the expression you specify etc. For amounts you have a possibility to choose from the expected selection of equal, greater, smaller, is (not) null etc.

Frequently used Field names are usually those corresponding to plants, internal orders, requestors ID, amounts net or gross, supplier ID, procurement units, commodity codes, GL account, account category etc. For supplier data update type of approvable it could be Catalog subscription names where you can take advantage of some, e.g. country specific, naming convention to route catalogs to appropriate approvers. Technically to define for the system that ,considering given propriety/table cell, all values should be considered valid, fill in “*”, same as you would in SAP backend software.

In case that the system will be presented with a requisition with proprieties that will match the defined combinations in the Approval lookup table, the PR will be considered for approval. There are several Approver Type Fields in Action area, where, depending on where you put your tick-mark, you can define different types of approvers to be involved in particular table a) Group – one of the groups created in your system. Advantage is you don’t need to change the approval tables all the time, but you need to maintain which users will belong to this group. Another option is b) User or c) Approver list. In both b) and c) you define in appropriate lookup table column ID(s) of Ariba users who should approve. The only difference is that for User you select only one ID, but you can put multiple to Approver List and separate them by colons. All users in the approval List will be asked to approve, but approval of the first one doing this will do. You can also combine User and Approver List. There is no rule that Approver List needs to contain more than one user ID. Hence if you fill-in both User and one user ID into the Approver list you can achieve a situation where both will have to approve in the given scenario.

Option d), Approver Field Path is used to define approvers not based on specific user ID, but rather based on specific role in the process. For example filling in Approvable.Requester.Supervisor will involve specific PR requestor’s supervisor maintained in the requestor’s user profile.

For each defined combination of PR proprieties and corresponding approvers you can define a Tooltip. In other words a text message which will be delivered to the approvers informing them about why they should be involved in particular PR approval.

TIP: Translations of the tooltips can be either a) written in the local language directly in the lookup table or b) there can be translation of given tooltip to multiple languages. To achieve that you will have to reach out to Ariba support and submit the translations. The syntax usually starts with “@” and it is filled in the usual tooltip place in the approval table. E.g. “@approve as supervisor” would be displayed to approvers as “Approve as supervisor” to users with English as system language and “Als Supervisor genehmigen.” For users with German.

if you intend to use special characters like “ü” or “í” for Ariba tooltips, make sure the csv is encoded in UTF-8 format, otherwise they might not be displayed properly. If the UTF-8 itself does not help, you can fill-in HTML code signs instead. For example “Proszę” to be displayed as “Proszę” to approvers in polish etc.

Column Required which contains values TRUE or FALSE defines if for given rule, i.e. lookup table row, approval will required or if the involved approvers will be only informed as “watchers”

TIP: Approver lookup tables work with top-down logic, meaning Ariba will start on the first row and will proceed until it finds a row with a rule applicable for given requisition.  This effectively means that you shut put more specific special rule on top of more general ones so they will have a chance to be applied. If the system will find the more general rule first, but for the given situation there is also another applicable more specific rule, it might assign different approvers then intended. Best practice is therefore the put most specific rule high and to create one general fallback rule on the last row. For purchase requisitions this could mean that you fill-in all columns with * to say that the row is applicable for every purchasing unit, commodity code etc. and put user’s supervisor to Approver Field Path. That way you make sure that every PR will have appropriate approval. In case there is no relevant rule/row, systems go through the approval table and even though the approval node was triggered because the conditions were satisfied, no approval will be assigned. It is also possible to tick mark “Add Multiple Approvers” in the Action. System will then add approvers from all relevant rows which will be found, incl. the fallback rule of created.

TIP: But what if you want to combine both approaches and trigger multiple relevant approver table rows and at the same time define a fallback last row rule for undefined general scenarios, with one little catch – that you don’t want the fallback rule defined approver to be involved together with above defined multiple specific approvers in case system finds any? Solution is to create parallel, almost identical, nodes. Alle conditions will be set the same as well as the loaded approver lookup tables. The only differences will be that for first node you tick-mark “Add multiple approvers” and won’t include the fallback rule in the table and for the second node you leave this field unchecked so system will always look for the first valid hit only and add the fallback rule to the approval table. If multiple specific rows will be valid for given requisition, then based on first approval node system will assign multiple approvers from different rows. In the second node Ariba will find only the first valid row, but since the approvers should not be duplicated, PR approval will involve this approver only once in the flow. Fallback rule is I the second table, but since there is higher positioned special rule, system won’t get to the fallback. One valid hit was already found higher in the table so Ariba won’t proceed to the bottom of the table. In the first node the fallback rule is not set at all. If there is no special rule relevant for given PR created, system won’t find anything in the first approval node table, where no fallback rule is defined, which means it won’t find any special rule in the second, basically duplicated, approval table either (remember – they are both the same difference being only the fallback rule) and will go all the way down to add approver from fallback rule present in the second approval table, e.g. user’s supervisor.

To involve Third Party users in the approval process, you can add column with header “PasswordAdapter” to the approval table. In case you assign only enterprise users on a given row you don’t have to fill-in anything there. If you decide to include IDs of your third party users, fill-in “ThirdPartyUser” to tell Ariba where to look. It is not possible to combine users of both types. PasswordAdapter is for Ariba distinguishing factor for users – you can have user with exactly same ID as soon as there is this distinction between enterprise and 3rd party one represented by PasswordAdapter.

What if you would like to involve in the approvals not only requestors’ supervisors, but in case of higher amounts also supervisors of the supervisors? That is when the Chain rule comes into play. Directly to the right from Title “Approval Rule Editor” there is an inconspicuous link called “Action” (Different from “Action” further down on the page). You can click on it and tick-mark “Chain this rule”. You will then get right underneath two tabs: Base rule and Chain rule. For the base rule you can then select action” Add supervisor” and for Chain rule “Add supervisor of Approver”. The chain will then respect Spend Limit value maintained for involved users acting as supervisors.

TIP: Last, but not least, few tips about adjusting and creating csv files in Microsoft Excel. Using Excel for working with csv files can much more convenient then text editors, because with the right settings, the comma separated values populate the right cells and the intended structure of a table is kept – values belonging to the same column are one on top of the other etc. which is not the case while opening csv files in text editor. However be careful that the file saved in excel is really what you want to load into Ariba – for example make sure you did not lose leading zeros for values where applicable and that the csv is still encoded in UTF-8 to not get into troubles with special characters.

I created this article since I still remember how hard to figure out some of the settings (that are now crystal clear to me) in the approvals area were. I hope that this post helps those who struggle during their initial system setup, wondering about the basic options, but my ambitions is also that even some of the veterans could hopefully find something new and useful to be implemented for them too.



Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.