Salesforce is most commonly abbreviated as sfdc (Salesforce dot com), presumably because San Francisco was unwilling to share the shorter acronym. Or, at least that’s my rationale for the extraneous ‘dc’.
I’m sure someone will tell me I’m wrong. As someone who is relatively new to sfdc, I can say this with confidence: everyone thinks they have a better answer. Answers are solutions and, whether or not others know they are right, their livelihood depends on them appearing right.
And, if they smell your lack of confidence, they pounce and you start questioning everything. Time is wasted validating what you already knew to be true because someone with x2-3 more certifications asked “are you sure?”
Which get’s to my point: the ‘dc’ should be short for ‘demands confidence’.
Side note, there is nothing wrong with asking the question, “is this your best work?” Admiral Rickover, dubbed the “Father of the Nuclear Navy” was famous for asking his subordinates if they had done their best. One of those subordinates was a future President of the United States. The “are you sure?” without any insight to a better solution, however, is malignant.
Getting Rickover’d
I recently had this experience; I was made to question everything and go back to the drawing board, only to discover weeks later that my initial research was correct. For background, I was attempting to send personalized, one-to-one, variable data emails on behalf of other sfdc users that appeared in the sender’s sent folder and avoided the dreaded “sent on behalf of” disclaimer in the email headers (dreaded because it is a spam flag, reduces open rates, and comes across as disingenuous).
Note: I will detail the full solution in a Salesforce how-to post by next week. Tl;dr – it isn’t possible using declarative sfdc tools (or even Pardot). You need a third party like Zapier, Microsoft Flow, or to develop your own app.
Point is, I researched and experimented. I did (with all respects to Admiral Rickover) my best work. But when I presented my efforts to the organization’s Sysadmin, he questioned whether or not what I was attempting was possible inside the declarative sfdc ecosystem.
And he did it with a simple “are you sure?”
That was my moment. I should have said “yes. absolutely” or, at the very least asked, “what leaves you to believe I’m wrong?”
Because I can say this next part with confidence
I (now) know I was right. It took me three weeks of painstaking research to be sure but, I can say this with confidence, as of Salesforce’s Spring 2019’s release, native declarative tools will not allow automations to send variable data emails on behalf of other users. You must to use an outside system like Zapier or Microsoft Flow. I’m still not sure if Marketo (and others like it) can do it (they probably can, others have told me that’s how they would do it).
If I’m wrong, correct me in the comments.
And a word about caution
Salesforce bakes caution into their platform. Your production environment can be sandboxed with a single click, you can have unlimited developer editions, and there’s Trailhead’s playgrounds as well. On top of that, you can’t deploy Apex w/o writing test classes that test and validate your code.
As strange as it sounds, that caution is liberating. The sandbox is my safe space where I can break everything and restart with new lessons learned. I can fail quickly and failure is the only guaranteed way to gain confidence.
Lessons learned
Going back to the lessons of Admiral Rickover and the “are you sure?” Sysadmin. Because that sysadmin doubted my solution, I learned two valuable lessons
1.) How to code in sfdc’s programatic toolset
2.) To be more confident next time
Oh and one more tidbit on confidence. If you want to learn how body language can help us feel more confident, you should check out Amy Cuddy’s Ted Talk from 2012.