Microsoft vs Salesforce: Simple Automation

Introduction

This walkthrough outlines a business request and what is required to create the same solution in both Microsoft and Salesforce. It is focused on organizations that primarily rely on a system administrator to make changes rather than a team of developers. It is reflective of our experience working across both platforms, and we hope it will help decision-makers understand the difference in administrative overhead between the two.

The use case is gathering some simple metrics about membership renewals for a nonprofit organization:

1. Quantifying the days between a renewal and a member's previous end date (did they renew early or after lapsing, and by how many days?)
2. Was the renewal an upgrade or a downgrade?

This could be accomplished with a BI tool without any database automation, but is the kind of request that is simple to build into a CRM as an automated process. This can be faster to create, more widely available to users, and used in business logic (special follow-up with long-lapsed members who renew, or someone who renews very early).

Our design writes the contact's current membership level and end date to the renewal record when it is created. This lets us handle reporting within the CRM: Contact purchases membership > membership record created > stamp Contact's existing membership information on the new record.

Results:

• Microsoft took nearly 3 times as many steps and twice as long to build the same functionality
• It is easier to introduce errors in Microsoft; success requires more attention to syntax, null values, etc

The process is compared below in a video, additional text commentary, and via steps documented using Scribe.

Next step: calculating days between dates

This video does not include the actual calculation to find the difference between the date the membership was created and the end date of the previous membership. In Salesforce, this is very straightforward: use one formula field to convert Created Date from date/time to date only and find the difference, in days, between that value and the Previous End Date field. This takes perhaps one minute and 10 clicks.

Although Microsoft offers two types of calculated fields ('calculated' and 'formula') neither is capable of directly comparing a date to a date/time value. There is no function we can add to the calculation to convert Created On from a date/time to a date. There are workarounds, but the effort and time to get a number are multiples of what it takes in Salesforce.

This is just one example

1. This flow is about as simple as it gets. The level of additional overhead required to build in Power Automate only goes up from here.
2. The Scribe steps and time for the Power Automate flow did not include any energy going into investigating the syntax. That is frequently part of the process especially for anyone not working in Power Automate regularly.
3. It is more difficult to troubleshoot errors in Power Automate. The error messages typically do not provide enough information to resolve the issue and require Google or ChatGPT.
4. Copilot has not proved to be an asset in either building or troubleshooting flows, even though it has far more context than ChatGPT or Google when trying to figure out what went wrong and where to go next.
5. We have found nearly all aspects of the Microsoft Power Platform to be significantly less user-friendly to work within than Salesforce. This is just a clear-cut example.

Any silver linings for Microsoft?

Yes.

Power Automate is not limited to Dataverse the way that Salesforce Flow is to on-platform data. It is, in many ways, closer to a middleware app. Example: you can use Power Automate to create documents in Sharepoint, without any add-ons. Salesforce requires 3rd party apps or custom development to accomplish this which is an additional cost however you slice it. There are some other 'nice to have' features not found in Salesforce—the ability to include columns from related records in list views, for example.

That said, the example shown in detail here highlights the cost inherent in the Microsoft platform. Configuration is slower and more error-prone in almost every respect, and to a significant degree. For an organization with strong Microsoft resources and a desire to use a wide breadth of the platform, that might be a fine tradeoff to make. For an organization using a more limited scope of the platform and with fewer technical resources, it might not.

Scribe

Here are the Scribe steps for Salesforce Flow (33 steps, 2 minutes):

And here are the Scribe steps for Power Automate (93 steps, 4 minutes):

Interested in staying in touch?

We send periodic emails related to data strategy and technology, focused on the nonprofit sector. You can check out our previous articles below, and subscribe for updates.