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?
  • 2
    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 – bigassforce Jun 3 '14 at 22:21

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:

| improve this answer | |
  • 2
    Outstanding! I want to favourite this answer. – bigassforce Jun 3 '14 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 '14 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 '14 at 17:53
  • 1
    That makes sense @jpwagner, but unfortunately that is more of a change process control issue than a development control issue. If non-development resources are making changes there should be a change process similar to development where those changes occur in a sandbox, have unit tests run, have manual testing done, and then everything is deployed to production. As a developer, our control is unfortunately limited compared to other platforms because of a number of possible changes a non-developer can make. – Jesse Altman Jun 3 '14 at 17:57
  • 2
    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 '14 at 18:17

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.

| 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 '14 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 '14 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 '14 at 17:51
  • 1
    I think we both gave good reasons to consider workflow for things like a field update @jpwagner. Are you looking for something different? There may be a few drawbacks in specific scenarios when combining field updates and Trigger behavior, but the benefits outweigh the negatives in most scenarios. The drawbacks can be worked around in those scenarios in my opinion. – Jesse Altman Jun 3 '14 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 '14 at 18:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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