I think a trigger would be the wrong solution for philosophical and for practical reasons.
The rules you mention sound like business rules, not data integrity rules. As such they should be in the "logic" tier of your application where the workflow, connections and transitions are managed. A trigger does not fit comfortably with this architecture.
Practically speaking, triggers tend to be forgotten. They're not well-integrated with the main flow of code. Their activation is opaque. Unless they form a central part of the architecture people forget they exist.
It is appealing to put this kind of thing in the database. Changes are likely to be frequent. DB code can be distributed and re-compiled on-the-fly at run time. The alternative is to parse out all the rules into (many) tables and have generic routines to implement logic at run-time. It is writing a new domain specific language within the application. Putting the logic in the main application requires a full rebuild and release each and every time the rules change. Even with CI/ CD this can be tricky.
One solution would be to put the frequently-changing rules into a script language, say Python, which is then called from within the main application. Here's one example in .Net. If you do choose to use your DBMS's scripting language to implement this I'd suggest using a stored procedure (SP) rather than a trigger. The app can call the data action and then this SP making the dependency obvious in code, or the app calls a single SP which has within it the data action and a subsequent call to the "special rules" SP.