I would say you have a few options here. My first choice would be a formula. Make it Text
type and then just use:
TEXT(Partner__r.Partner_Fee__c)
If you decide formulas aren't right for you and prefer to go the Workflow Rule
route, that is still the formula you would need to use in a Workflow Field Update
as well. In such case, your criteria there should simply be:
OR(ISNEW(), ISCHANGED(Partner__c))
You will need to implement Process Builder
to sync the value back down to the child Customer__c
records when Partner_Fee__c
changes on the Partner__c
record. There are many steps involved here, but the ones that may be tripping you up are:
- Criteria
- You should update the child records whenever
Partner_Fee__c
changes.
- Action
- You should
Update Records
and select the child relationship.
- Select the
Field
you want to update and use update Type
of Formula
- The formula should simply read
TEXT([Account].Partner_Fee__c)
I'll give this one a shot.
disclaimer: The only experience I have with process builder was helping my boss out in the Dev Zone at Dreamforce last year.
Process Builder is a tool that sits in between workflow and Apex in terms of what it can accomplish. Process Builder can be the best fit for the task at hand, but like all tools, it can be misused.
The big advantage to Process Builder is that it gives you a sizable portion of the power of Apex code without the need to actually write Apex code. You just need to have a somewhat programmer-ish mindset (knowing how to make use of loops, variables, and conditionals).
Having even a single developer on staff can be a big investment for a company. Process Builder allows some of the benefit of a dev, without the full cost of a dev. It saves money...for a time.
I'd argue that using Process Builder means that you start to accrue considerable Technical Debt. The numerous downsides that you mention are all technical debt.
The scenario you describe sounds like someone has (or several people have) succumbed to the Law of the Instrument, which, restated, is
When you have a golden hammer, every problem starts to look like a nail
Process Builder helped them out on problems x and y, so it should work for problem z too, right?
Well, after some ill-defined point, the processes start getting more complex. They also start to become more tightly coupled, and interact with one another more and more.
In your situation, it sounds like there's an issue of shared resource planning as well. One business unit may not have/want a dev to take care of this, but it will end up impacting the rest of the business units.
It is at that point where I believe you cross the line in the sand where a developer writing Apex makes more sense. Some of the value of a Good Dev™ is that they are able to manage the interactions required between the business logic in a way that scales well, is easy to maintain, and is easy to extend.
The takeaway
Process Builder can be used to solve a variety of issues, but it isn't always the right tool and is no substitute for a competent developer.
The situations where I'd consider using Process Builder are:
- When you are only performing work on a single object
- You aren't trying to work on more than a hundred records or so
- The required logic isn't terribly complex (a couple of
ANDs
and ORs
at most)
- You can't afford to hire a dev right now, but will be able to in the near future (< 1 year)
Used correctly, Process Builder can serve as a replacement for simple triggers until your org needs to start considering code scaling. It even may be faster to develop than a trigger.
Moderately complex logic and interactions with other objects are a good way to quickly get over your head, and would require more up-front cost when a dev is brought in to untangle the unholy mess.
Best Answer
First of all, this is an excellent question and I am writing best as per my opinion which can vary with others.
Considerations
Process builder works good in following scenarios.
Where as both process builder and flows do not support Outbound messaging, here workflow is advantageous.
Here, if the same type of actions lets say, create a task, field update, send a email can be perform both by process builder or workflow, then stick to either workflow or process builder, Do not mix it here.
Null checking logic in process builder throws error message so, here workflow is advantageous.
Process builder/flow debugging mechanism cumbersome, here workflow is advantageous.
Regarding flow, if you have simple UI then rather than using Visualforce you can use Flow. Through flow handles process logic just like apex but, apex is more optimized than flows. I usually prefer apex, though using flows, we don't need to write test classes (so less components in the org).
Flow and Process builder's process executes after workflow action and here you need to check the sequence of logic how you want to perform either in workflow or in process.
Workflow rule and Process builder executes in system mode, where as flow works in user mode.
Visualflow - User, but -
Refer this answer Types of execution - System mode or User Mode?
Workflow always takes most recent version where as flows and process builder we can manage versioning.
I have faced issues when we have large number of process builders, workflow and flows then we received
Apex CPU Limit exceeded
errors for large amount of data processing in a transaction. So, in that situation, we have put most of the logic in apex classes rather than process builders.Normally, for bulk data load, we need to deactivate process builder and workflows and preprocess the data outside of Salesforce and migrate the data.
Again, think about automatic bulk data updates how those can be handled.
So, basically above points can help you what will be best suited according to your need.