Automation Basics

As CATS has grown, the amount of work required by IV admins has become increasingly cumbersome. A clear example of this is the sheer amount of shifts that require approval when being created. Rather than sifting through each created shift, it was agreed to automate (or semi-automate) this process. In order to accomplish this, each form of automation was ran through several planning sessions until the automation rules were agreed upon. These rules will be detailed in their own respective readme files which can be found in this same directory. As for the implementation of said rules, the following architecture was decided upon as the best solution at the time of their creation.

Rule Check / Application

The most logical approach to defining the rules was to define them on the model’s service. This allows us to keep the business logic outside of the model. However, it may make sense to have an AutomationService in the future that holds all automation rules. More conversation can happen on this later.

Example

Automate the process of publishing a shift that meets a certain criteria.

$shiftService->canBeAutoPublished($shift) // should return true or false based on the rule criteria \ $shiftService->autoPublish($shift) // will complete the publishing of the shift

Both of these functions will be defined in the Shift class in app\Services\ShiftService

Rule Automation

The actual logic of the rules will be placed in the model’s respective service until it is agreed that it should reside somewhere else. However, the rules will need to be ran according to some cadence. For now, the rules will be checked and applied based on Observer methodologies. Laravel allows developers to define observers which will fire based on some eloquent CRUD action. These observers can be found in app\Observers.

In the shift example above, when a shift is created, under the created() function for the ShiftObserver, canBeAutoPublished and autoPublish will be fired thus automating the process.

Automation Agency

The agent responsible for running the automation will be a system user that has been created for automation purposes. It seems likely that there could be different agents for different tasks with different roles and permissions so, it seems that it would be best to have bots related to the task being automated. Automated shift approval, for example, is a task currently being performed by an Indevets administrator and thus, it makes sense, to have the user be an Indebot Administrator. More users can be created if needed.

Approved and Implemented Automations

Shift Approvals (June, 2022 / Sprint 78)