Custom code is the most powerful tool available in a workflow and the one most often reached for too early. A rule expressible with dropdowns should stay in dropdowns, because the next person to maintain it will thank you.
There are, though, problems that configuration genuinely cannot express, and working around them tends to produce worse systems than simply writing the ten lines.
Signs you do not need code
If the task is reformatting a value, mapping one list onto another, extracting a substring, doing date arithmetic or associating records by a shared value, there is a configured action for it. Those run faster, fail more clearly and need no maintenance.
Reaching for code here usually means writing something that a dropdown already does, and owning it forever.
Signs you do
Logic that depends on several inputs at once, like a scoring model, collapses into branch sprawl when expressed as conditions. In code it is a dozen readable lines in one place.
Calls that require a signed token, a multi-step exchange, or a response that must be interpreted before use are the same story: possible to fake with a chain of steps, far clearer as code.
Keep secrets out of the workflow
Credentials pasted into a workflow field end up in screenshots, exports and audit findings. Storing them encrypted and referencing them by name in code keeps them out of the places people look.
The same applies to data you must share but should not expose: hashing identifiers inside the workflow means the raw values never leave the CRM.
Build it
Each of these is a working pattern with the exact steps, using the actions this article describes.
A good rule: if you can describe the logic as a sentence with no conjunctions, configure it. If the sentence needs three clauses and a caveat, write the code.