Approval workflow challenge

How to build & run with a custom invoice

./gradlew clean build
./gradlew run --args='1 5000 Finance false'

• arg1 is an int for the companyId (already prefilled for 1)
• arg2 is a decimal for the invoiceAmount in dollars
• arg3 is an enum for the department (Finance, Marketing)
• arg4 is a bool for requiresManager

Quick command list from the Flowchart scenarios

./gradlew run --args='1 15000 Marketing true' # Sends request to marketing chief via email
./gradlew run --args='1 15000 Finance true'   # Sends request to finance chief via slack
./gradlew run --args='1 6000 Finance true'    # Sends request to finance manager via email
./gradlew run --args='1 6000 Finance false'   # Sends request to finance employee via slack
./gradlew run --args='1 4000 Finance true'    # Sends request to finance employee via slack

Test them out and check the logging to verify! Note that the default chief_threshold is $10,000.

Assumptions

• We assume every department has at least 1 Chief, 1 manager and 1 regular employee.
• All Chiefs are managers, but not all managers are Chiefs and the same goes for managers and employees.
• When we want to notify a manager we will not notify a chief unless the invoice amount exceeds the chief_threshold.
• The same goes for employees. When we fall back to some rule or invoice which does not require a manager, we will only notify an employee that is not a manager.

Design:

• A workflow can specify the amount which will always requires a Chief approval called the chief_threshold.
• If no conditions are met, send the request to a regular employee of the department attached to the fall back rule.
• For currencies we use BigDecimals in the database and application to maintain precision.
• Priority of rules are evaluated by descending order of the cutoff_amount then the department and finally the requires_approval.
• An approval request will be sent to a manager if both the invoice and the rule require manager approval.

Possible Improvements:

• We currently retrieve big data sets from the Database at once, preventing lots of manual lookups. On production a wiser thing could be to split this up into multiple queries to avoid huge memory usage.
• The primary keys use auto-incrementing integers but in production probably a UUID would be a better idea.
• Currently a rule can only have 1 set of conditions and 1 set of actions but this can be modelled to allow for several conditions and actions per rule.
• Allow for the possibility to assign manual priority to a rule as now all conditions are simply evaluated one by one.

Database ERD:

Flowchart: