The Approval Rules section is where you can supply the rules which determine who approval requests are to be sent to.
There can be any number of different business rules, from the simple to very complex, involved here. Rather than create a dedicated rule interface in Builder for you to try to build them directly there (which would be very unlikely to cover such a wide range of required business scenarios), we instead use an approach where you can upload an Excel file where you can define whatever business rules you need to, as long as the result passes up to Enate the names of the individuals who are to be the approvers.
You can download an Excel template from the Approval Rules section of the System Settings page in Builder that you can use as a guide for your own rule creation.
The first sheet of the template contains instructions about how you should correctly format your own approval rules.
Some of the excel template consists of standard sections where you'll need to provide data in a certain way, while other sections are more freeform where you can enter whatever business logic you need to. Note that the variables defined will need to be information Enate has access to, and the Approvers specified will at least need to have a Contact record set for them within the system.
The Input Parameters sheet is were you define the values that they will use in their rule conditions.
The Rules sheet is where users define your rule conditions. These rules should be based on the Input Parameters specified in the Input Parameters tab.
The Approver sheet is where you provide their approvers, and their approval levels. When an approval process is triggered in Enate, Enate will use these values to determine who to send the approval request to.
Whenever an Approval Action is triggered in a workflow, Enate will automatically run through the rules in the Excel template (passing in whatever variable values are asked for from the work item) extract the resulting approver names and email addresses and then send the approval requests to those individuals.
Once you have uploaded a valid rule file, it will be marked as having 'Validated Changes' .
This means it can be used for testing in Work Manager using test mode. Once you have done your testing and you are happy with your rules, set the rules sheet to live so that it can be used in live processes.
You can also download, delete and view the activity history of the rules file using the ellipses menu on each uploaded sheet.
At runtime, if an approver decides to decline a request, they will have to specify a rejection reason.
The rejection reasons they can choose from are set the 'Approval Rejection Reasons' section of the System Settings page in Builder.
There are a number of default, out-of-the-box reasons, which include:
If these don't quite meet your needs, you can also create new rejection reasons. To create a brand new reason, click on the plus symbol.
Give the reason a name and a description and click to create.
You can always edit a rejection reason after it has been created by clicking on it and editing its details in the subsequent pop-up, and you can delete a reason by hovering over the reason and clicking on the 'X'.
| Rejection Reason | Description |
|---|---|
Budget Constraints
The requested funds exceed the allocated budget or available funds for the specified period.
Duplicate Requests
The same request has been submitted multiple times.
Incorrect or Incomplete Information
The submitted data or documentation is inaccurate, incomplete, or contains errors.
Missing Supporting Documentation
Required supporting documents, such as invoices, receipts, or contracts, are missing.
Policy Non-Compliance
The request or transaction violates company policies, regulatory requirements, or compliance standards.
Vendor or Partner Issues
The proposed vendor or partner has encountered issues or concerns that impact the request's viability.
