1. for non-trivial business logic which is confusing/unclear
2. when I need to explain or present it to others
3. when I need to explain it to myself (similarly to Rubber duck Debugging [1])
4. when starting working on a new codebase, especially if it's poorly-documented and/or legacy
Also, you don't need to create flowcharts for the entire program/application, only for the difficult parts. Likewise there is no need to document the non-functional parts, i.e. stuff done by the framework or common libraries.BTW: flowcharts are less useful in general and can be easily replaced by pseudocode. IMO the most useful diagrams in Software Engineering are MSD (Message Sequence Diagrams), then Call Graphs [2] (sometimes can be created automatically with profilers/intrumentation/tracing tools), then dataflow diagrams.
State Machine diagrams and ERDs[3] are also useful when applicable.
--
1. https://en.wikipedia.org/wiki/Rubber_duck_debugging
We use Plectica[1], but there are a bunch of good tools that can do this.