Take the 2-minute tour ×
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

I'm trying to build a development philosophy around Salesforce development. Can I solicit your opinion on:

  • Why would you ever use a workflow for a field update?
  • Why is a workflow better than apex code for doing communication (emails, messages, etc)?
  • What is a good development practice for separation of when to use workflow vs apex code?
share|improve this question
1  
Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options. - Jeff Atwood, undercover salesforce evangelist –  user320 Jun 3 at 22:21
add comment

2 Answers 2

It is always better to use declarative Salesforce functionality over Apex when possible. The reasons for that include:

  • Flexibility - Changes do not require a developer. Changes should be done in a sandbox for proper testing, but being declarative allows anyone to make necessary changes rather than needing to tap into a development resource.
  • Reliability - Salesforce's team is larger and more thorough than your testing team. That is going to be a fact in 99.9% of the scenarios you may encounter. The declarative platform will just work and you won't have to worry about some small programming mistake derailing something.
  • Limitations - Declarative functionality is not limited by Governor Limits
  • Speed - In almost all scenarios, using the declarative framework will provide a much faster implementation than trying to custom code something.

You need to approach Apex completely different than a traditional programming language because it is really a programming platform. Use the platform wherever you can because it is easier, faster, and more reliable. Apex should be a last resort, not the go to.


As someone looking to create a development methodology for Apex, you may find the following useful:

share|improve this answer
2  
Outstanding! I want to favourite this answer. –  user320 Jun 3 at 17:26
2  
Can you add a comment about how you approach test coverage for this declarative logic? I'm not talking about 75% targets but about how you ensure your declarative logic is doing what it should over time as additions and changes are made. –  Keith C Jun 3 at 17:35
2  
I've had an issue precisely with the development team not being the ones who make changes to workflows. Thus they are not part of our version control or testing. This causes its own headaches. –  jpwagner Jun 3 at 17:53
1  
I truly appreciate your perspective(s) but there's some contradictory info here: "Changes can be made directly in production" but "there should be a change process similar to development where those changes occur in a sandbox". Similarly if you're testing etc then it's not removed from the development team's plate. The governor limits pose reasonable guidelines and force developers to query better. There are few valid scenarios that need to go beyond and I think none would be better handled in a workflow! –  jpwagner Jun 3 at 18:03
1  
By the way, to be perfectly clear, as with most things in development, there are many ways to do any task. If you have reviewed the workflow field update logic and determined it would work better in your situation to use Apex instead, that is an acceptable stance. Just make sure you can detail why it makes sense in that scenario to use Apex. There really shouldn't be any performance degradation from the end user's perspective. At this point it does sound like you considered the options, so now it is just up to your team to determine how you want to do it. I hope that makes sense! –  Jesse Altman Jun 3 at 18:17
show 4 more comments

In addition to Jesse's great answer, the one item that I would add to his list is technical debt. Every line of code costs you as an organization, to maintain and update. The advantage of workflow is that much of the technical debt of automation (not all, you still have to build and maintain the workflow rules) is assumed by salesforce.com and the platform.

A corner edge case also worth mentioning is that workflow rules that fire a field update and triggers do not play as well together as they should. Field updates can cause strange behaviors on an object with a trigger, often causing a trigger to fire recursively (at least one additional time) in a transaction. The other interplay between field updates and triggers that is problematic is when you need to tightly control the order of execution, like wanting a field value updated before running triggers.

share|improve this answer
    
the "strange behavior" is precisely what should be eliminated by enforcing a "all field updates occur through <this-method>" type of best practice. –  jpwagner Jun 3 at 17:47
    
While I agree with that aspiration, you can't always accomplish what you need to with workflow alone. For the benefits Jesse mentioned, workflow may be preferable for at least one function. As long as you understand the interplay as a developer, you can adapt. –  greenstork Jun 3 at 17:49
    
if you read my original question you should understand that i'm looking for why you would even consider using a workflow for things like a field update. if your best practice is "all field updates must occur through apex code" then it's covered by testing, easy to document, and properly managed in one place! –  jpwagner Jun 3 at 17:51
    
I come from a dev team that mostly shies away from ever using workflow for field updates, for the issues that I mentioned. Still, workflow is so easy and fast that it's sometimes favored. I would also add that workflow can be unit tested with apex. Combined with a CI system, you could catch workflow changes that break your build. –  greenstork Jun 3 at 17:54
1  
I think your answers are reasonable (although sometimes contradictory) for a small to medium amount of Salesforce customization and development and I truly appreciate your feedback. –  jpwagner Jun 3 at 18:05
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.