Rollup summaries are a necessity in Salesforce implementations in general, and document generation solutions in particular. Quotes, orders, and invoices are full of Totals, Sub-Totals, and SUMS by product types and categories. There are MAX and MIN end dates for subscription services. Account records require reporting metrics to break down total products, orders, and support ticket cases. MRR and ARR calculations are fundamentally sums of products by type.
Mature Sales Cloud and CPQ solutions ultimately end up deploying 100+ rollup summaries across a variety of Salesforce objects.
Rollup summaries are the go to “secret sauce” solution when creating complex CPQ conditional rules based on prior purchases, terms, and other products in the shopping cart. For example, “IF a Subscription product is being sold for a 2 year term, then add-on product Y shall be discounted at Z%”. The trick in this case is starting with a pre-calculated rollup summary for Total_Multi_Year_Subscription_Products and letting the Flow check if the value is greater than 0.
And utilizing prior purchases in quote flows is a matter of referring to rollups of Assets or Line Items at the Account or Contract level.
The ultimate beneficiary of cross-object rollups are reports and dashboards. The slice-and-dice and pivots possible make every Salesforce Admin look like a business intelligence hero with all the summarization quantities, amounts and discounts. And most importantly, reports and dashboards run 5X faster when using pre-calculated values.
But accomplishing "rollup nirvana" using Salesforce rollup summaries out-of-the box is very limiting. They only work in strict Master-Detail lookup relationships and can only operate on literal fields on child records (no formulas or relationship fields).
Packages like the Nonprofit Success Pack, which are very currency and rollup-driven, built their own customizable rollups module to address this need.
Most Salesforce Admins turn to add-on AppExchange packages to help with rollups, and more recently some Flow hacks have emerged to update rollup summary fields in flows.
Our specific solution required pre-packaging several rollups to be made available out of the box and had to be invoked via flows.
We arrived at the perfect solution by utilizing Salesforce custom metadata types (MDT) to declare, package and deploy rollup summary definitions, and a single Apex action to execute rollup summaries.
The details of the solution can be found here. Our product roadmap and accelerators will now start to include pre-built document templates and rollup summary definitions so Salesforce Admins can instantly deploy complex solutions in only 1-2 hours.
There is no charge for this add-on functionality. It's included in iDialogue versions 1.242 and above.
eSigned documents with embedded links to an online verification service allows all parties in an agreement to audit the chain-of-custody and trust the document has not been modified since signature.
Whatever a person’s intent may be when verifying an eSignature, iDialogue now makes this process simpler with a unique identifier embedded beneath each eSignature with a hyperlink to an online signature verification service.
The verification service provides a centralized, secure, system-of-record for every signature. If a document is modified post-signature, the file size and hash code signatures are readily available for comparison.
For Salesforce users, the verification service provides additional visibility into the specific Salesforce records the agreement originated from.
This service went live in October 2022 is generally available to all customers.
There are a number of use cases where a Salesforce Admin or Developer may want to handle File upload events using Salesforce Flow Builder. Example use cases include:
iDialogue raises CONTENT_VERSION_INSERT and CONTENT_VERSION_UPDATE platform events for these types of use cases (note: as of Winter '23, "Record-Triggered Flows" did not support ContentVersion object types. This platform event approach provides an equivalent alternative).
Implement this solution in 4-steps:
1. Begin by creating a new Flow of type "Platform Event-Triggered Flow".
2. Select the "iDialogue Event" type.
3. Add conditional branch decisions to check for ContentVersion Insert and Update events.
$Record> Event Type = CONTENT_VERSION_INSERT
$Record> Event Type = CONTENT_VERSION_UPDATE
4. Finally, add any custom flow handlers to process the ContentVersion insert or update events, such as making callouts to the iDialogue Content Intelligence API for file processing.
Note: that these platform events are always raised in an AFTER trigger context.
I watched Marc's recent appearance on CNBC with great interest where he addressed the market's near-term volatility (YouTube link).
"I’m mentoring these CEOs and I’m telling them there’s things they must do right now. Number one, they must move to long-term contracts…. secure the relationships with your customers. Don’t allow this kind of short-term volatility to effect your revenue or cash flow."
- Marc Benioff
This is precisely the buyer experience iDialogue enables, the ability to generate multi-quotes from a single opportunity and give the buyer a rich, personalized experience to review their options and quickly commit to a long-term contract.
"A great Buyer Experience starts with a great Employee Experience."
From a Salesforce opportunity, a Sales Rep can quickly configure a multi-quote room with options for 1, 2, or 3 year contracts.
A personalized quote room link is shared with the buyer (via iDialogue enhanced quote emails) where the buyer can review contract options, pricing calculators, and product brochures.
For any CEOs, Revenue Ops, or Sales Executives looking for a pre-built playbook for long-term contracts, please feel free to contact me anytime email@example.com.
A headless content management system, or sometimes called an "API First" CMS, decouples the front end clients, aka “heads”, from the backend “body”.
This is in contrast to Web 1.0 content management systems that were more monolithic and primarily evolved from desktop website content only.
Examples of how this technical architecture delivers business value:
The iDialogue API is an example of a headless CMS that primarily uses Salesforce as the backend, plus connects with other best-of-breed web services.
Example of front-end apps using the iDialogue API:
All of the above front ends are centrally supported through a single API.
The iDialogue API also proxies access to various back ends:
iDialogue broadly defines "content" as any customer-facing digital asset, including:
You've configured a perfect Quote/Opportunity in Salesforce and it's approved for delivery. Congratulations! So what is the next step?
Sending a quote as an email attachment is a common practice, but raises many questions.
Using Salesforce email templates with iDialogue extensions offers a better solution for quote delivery.
The ROI is tangible and very real:
Example of product bundle configurator included in iDialogue package, based on Unofficial SF flow components.
“The ability to provide spreadsheet-like functionality in Salesforce flows, plus integrate the components with iDialogue’s digital experience actions and platform events, enables Salesforce Users to easily interact with their customers” said Mr. Leach.
As Unofficial SF goes through packaging and versioning changes, iDialogue will maintain compatibility with key Unofficial SF components so that Flow Developers receive seamless, periodic component updates without the overhead of managing multiple packages, or keeping up with open source library updates.
In the spirit of open source, iDialogue will submit pull requests and enhancements to the UnofficialSF Github repository to ensure its long-term success, plus provide Flow training to iDialogue Admins and Developers.
Unofficial SF Github Repository
Eric Smith's Blog
Many blind people use screen readers to access web content. For Sales Enablement content creators, it is essential to understand how blind people use the web, and how to create Sales and Customer Experiences that are both operable and understandable by people who are blind .
Salesforce maintains Section 508 conformance for internal Sales reps. External customer-facing experiences must similarly be accessible for balanced, 2-way online "dialogues" with customers.
As customer experiences get increasingly interactive, it's important that they do not sacrifice basic accessibility for trendy features.
We recently submitted iDialogue Customer Experience (CX) rooms to several site checker and accessibility audit sites. And to be honest, I was bracing for the worst given the level of pre-built interactive screen elements.
The good news is that our accessibility scores all passed (95/100 from accessibilitychecker.org ), but there is still some work to do. The functional elements of a B2B Sales customer experience, such as accessing documents and quotes, filling out forms, and submitting payment methods, are all passing.
While iDialogue Room Builders can reliably build compliant and accessible rooms today, we've updated our 2022 product roadmap to reaffirm our commitment to section 508 conformance, and to be transparent in our progress towards achieving near perfect accessibility scores.
Generally speaking, a career in the Salesforce ecosystem does not require coding skills. A core principal of the platform is based upon no-code / low-code / declarative configuration. Agile companies want to move fast and respond to change, and the ability to point-and-click when making changes gives companies a competitive advantage when using declarative tools and processes.
Companies prefer to hire people with business domain knowledge that can quickly convert business requirements into cloud-hosted solutions that scale ubiquitously. Writing code, developing unit tests, and managing multiple sandbox / dev environments slows the business down and increases operational costs.
However, thinking like a coder in Flow Builder will increasingly become an in-demand skill and increase demand for your skills, while making your organization even more agile (more on this below).
When flows are utilized in iDialogue implementations, I'd speculate about 50% of the configuration was anticipated using pre-developed template flows included in our managed package.
Even distinctions like SMB vs Enterprise, or annual revenue are no longer absolute criteria for when Developers are required. It's not uncommon for startups to evolve into $100M+ companies using an entirely declarative approach to Sales and Enablement.
This is in stark contrast to when I first entered the Salesforce ecosystem around 2006, and pretty much every custom business rule required an Apex trigger. But today, as I write this in 2022, the combination of Lightning page builder and Flow Builder, plus our own Document and Room Builder tools now provide Admins and Ops with 100% declarative configuration environments to build end-to-end Sales processes and apps.
While coding is no longer required, I will say the ability to think like a coder when using Flow Builder will increasingly come into demand. Flow Builder has achieved 4GL status in recent releases; and as such, implements basic programming concepts like variables, collections, conditional branching, looping, and assignments; much like you'd find in many programming languages.
The ability to name things correctly, refactor larger flows into smaller sub-flows, test, and manage version control processes are necessary skills when building Flows. However, a new ecosystem is evolving that provides pre-built essential flows, allowing Admins and Ops to simply configure last mile details. So ultimately, knowing the inner workings of flows is useful, but not required.
Going forward, our measurement for success will always be to enable declarative configuration for all features. And as we grow and learn from our customers, we'll continue to evolve iDialogue in ways that increasingly offer sophisticated Sales Enablement, Content Management, and Customer Experience features without the need to learn or know code.
Is your Marketing department involved in Salesforce Opportunity page layout decisions?
Sales Reps spend up to 400 hours per year searching for deal-specific Marketing materials.
Lightning page layouts allow for cross-functional alignment across Sales and Marketing to ensure customer-facing conversations and quotes carry their intended messaging.
Marketers are skilled at pixel-perfect user interface design decisions, copywriting, audience targeting, and messaging. So why wouldn't you leverage their experience and bring their skill set to Opportunity page layout decisions and enablement rules?
Benefits to adding Marketing content to page layouts: