The <Requests> view is the core screen where the user activity happens on Oable. Here you will find all the Requests that are designated to go through the approval and payment workflow. If no automation is set up, each of the stages below require the user to make certain manual decisions by the end user. However, typically the configured Agreements have always some level of automation to make approving and denying requests as smooth as possible.

A video explaining the workflow can be found below, as well as a written explanation of the steps.

See more here regarding the Agreement automation options.

This is the initial landing stage any request. In many cases, imported requests are automatically processed so that it directly moves into the next stages of assigning the request to an agreement. In case of a manual process, the required Task by any user is to "Start Processing" in order to move the request further in the workflow.

When the request enters <Assign Agreement>, it means that the process has started and that the Oable workflow has been initiated. Depending on the automation settings, Oable might attempt to assign the request to an agreement. This is the default setting for all Wiley integrations. If that is not configured, the Task in the workflow is to click on "Assign Agreement" and manually select the associated Agreement from the list.

When an Agreement is assigned, the Oable system knows what the Eligibility and Payment rules are. In case of a manual workflow, the request will be in "Ready for Approval" and the corresponding Task is "Approve / Deny". When clicking on Approve/Deny, the pop-up window will display the compliancy check as to whether the request matches the Agreement Eligibility criteria. At this point, the request shall be marked as "Approved" or "Denied".

Note: this decision is also be propagated back to the original publisher, so that both Oable and the Publisher System are synchronised.

In this Stage all the approved requests remain that have been approved and not processed further. Here, you can set up payment transactions for an approved request by selecting the Plan Transactions button in the bottom right of that request's info pane.

If you plan a transaction but select Save, the request will move to <Transactions Planned> stage. If you select Save and Pay, the transaction will occur immediately and the request will move to the <Paid> stage. If you select Save and Pay but the transaction fails for any reason, the request will go to <Transactions Planned> instead.

In this Stage all request lands that have been denied. Note that requests can be reprocessed from here by clicking on Task "Re-process".

The "Transactions Planned" stage means that the request has Transactions associated with it, but the transaction was not and/or could not be finalized. If an error occured during the payment attempted, this will be noted with an error message on the request, as shown below:

When such errors occur, the "Plan Transactions" Task should be entered again until payment can be made successfully.

In those cases where a partial payment could successfully be transacted, but there remains an Open Balance the request will end up in the "Not Paid" stage. From the "Not Paid" stage, the Task can be to Try Payment again and therefore fulfill the Open Balance.

This is the end stage of a request. When the payment was succesfully carried out, and a Transaction has been created, the request will end here and is marked as Paid. Metadata can still be added or changed, while the Transaction can also still be re-processed in case of mistakes and thereby moving the request back to "Transactions Planned".

The Cancelled stage enables requests to be taken out of the Approval/Denial workflow as they might be withdrawn, rejected or simply wrong. Such cancellations are driven by publishers updating Oable on these changes via the bespoke integrations.