Trigger VS Process Automation
The short answer is that you should use a Trigger when you cannot do what you want to do with the declarative features of Salesforce. Salesforce best practice states that one should leverage the declarative features of Salesforce first (#8).
Process Builder is improving with almost every release, and can be used with more and more complicated use cases. This link provides very helpful scenarios where Process Builder would be preferable to Triggers.
That isn't to say that Process Builder is a 'silver bullet' - there are still considerations to take into account. As per this link, I think the most compelling consideration is that from @cropredy:
If you use triggers, you are forced to write testmethods and if you do a good job of this (lots of asserts, positive and negative tests, ...), you'll end up with a comprehensive set of regression tests
If you use Process Builder, this testing requirement has to be met in other ways:
- A browser automated testing tool (Selenium)
- Your own (possibly haphazard) UI testing before release
- Wait for users to complain something isn't working
- Apex testmethods that simulate the CRUD event and then assert expected results
Slightly unrelated to your question but quite interesting is that the gap in time investment between Flow and relatively simple Apex triggers isn't that much, so as per the Apex Academy video tutorial series on Pluralsight, it may be more beneficial and less 'technical debt' to use triggers in that particular use case.
As a good practice you should always try to use formulas, workflows or processes over a Trigger as it is easier to maintain and update. However in some cases the business process might be too complex for the options mentioned above so you would need to use a trigger in this case.
Consider the following scenarios 1): you need to assign ownership to a custom object based on some criteria. You can achieve this with with both triggers and process builder but the process would require a new process each time a change is require so depending on the complexity level it could become very hard to administer all the rules in the process builder.
Overall the main issues with process builder are :
editing ( you cannot edit a process once is activated)
autosave ( you can't cancel out of a process if you made unwanted changes),
- debugging (the UI doesn't allow the admin to see the created_date , id or created_by of the process),
- validation ( processes don t trigger validation rules)
- deletion ( you need to wait 12 h after making a process inactive to delete it) etc.