Differences between Salesforce Professional Edition and Enterprise Editions
We get asked these questions pretty frequently:
- What's the difference between Professional Edition (PE) and Enterprise Edition (EE)?
- What justifies the increased price?
- Do I need the functionality?
- Can I get away with the lower priced version?
I'll try and answer that.
From numerous customer encounters we'll explain the 3 most important differences. These, in my opinion, rely on business purpose and application rather than a simple use of a feature or function. The explanations are additions contained in Enterprise Edition not contained in Professional Edition - this is not a comparison of all features to check if either or both contain it. That could take some time and is covered elsewhere.
The 3 big differences. It's all in the tools.
1. Process Automation
Process automation keeps the wheels of Salesforce turning smoothly. It also keeps the wheels of your organisation turning smoothly. As the name rather obviously suggests it automates your business processes by doing stuff so you don't have to. In my mind, it's one of the most important elements of a modern information system.
Process automation tools allow you to define an event and an action. An easy example is a sales opportunity over, say, £500,000 value with a sales stage that updates to “Proposal Accepted” (the event). When that record is saved process automation could allow you to send an email notification to a Manager and set a task for the Sales Rep to review the deal with Legal (the action). The Manager could look at a report and the Sales Rep should get in touch with Legal, but does it always happen? Process automation means the Manager will receive a notification email and the Sales Rep will have a task created.
Another example is days in sales stage. Salesforce counts the number of days a sales opportunity is in a sales stage allowing you to see which opportunities are stuck. Organisations everywhere miss stuck opportunities. Process automation allows you to monitor stuck opportunities over a number of days and send a notification to alert you when an acceptable limit has passed. The Sales Manager will receive an email and demand a good explanation from the Sales Rep. I'd argue that most Sales Reps won't let days in sales stage slip if they know an unemotional workflow is ready to tell tales about them to their Manager.
Let's stand back for a second and remind ourselves that both PE and EE record opportunity values, sales stages and days in sales stage. Both can also generate reports and dashboards to tell you the status of all 3. The functions are common to both versions. The difference and I believe a big difference, is the power of process automation. EE will send a notification when an event has occurred, PE won't (PE allows you 5 workflows via Process Builder but those get consumed very fast).
Process automation is more than sending emails. For us, field updates are probably the most common workflow rules. This allows Salesforce to fill fields based on other records saving time and effort. We have a customer that sets a target date against each sales stage. If the date for the current sales stage is in the past a checkbox against the field "Opportunity at Risk" is checked and an email is sent. As a result of that automation fewer opportunities are at risk.
Code allows us to add and extend standard functionality to do pretty much anything you like. EE has this capability, PE doesn't.
I have to start this by saying you can do a lot with standard point and click tools in PE. You can build new objects, assign and assign fields. As pure data containers this capability is really useful. It means any PE user can extend Salesforce is a quasi-bespoke way, just remember you're limited to capturing and reporting on data not processing that data (much...).
Apex is the name of the Salesforce development environment which allows us to do pretty much anything we like. If standard functionality can't do it, Apex probably will. We always push customers to work with standard out-of the box functionality where possible but if a customer needs to go off-piste we'll accompany them down that route. We have a customer that sends emails based on project dates. This can be achieved with workflows but what happens if the project dates change? Once a record is saved and the workflow has fired there's no mechanism to revisit the record to check if that date changed. To solve this issue we used Apex to check back on the project dates to see if the've changed. If they've changed, the email is sent at a different date.
If standard functionality doesn't perform a function you need and you can't get a workflow or formula to solve the problem you probably need some Apex and it's a common reason customers upgrade from PE to EE.
An API is an Application Programming Interface. Recently, it's become a frequently bartered acronym. API's are gateways to data that allow applications to talk in a managed and secure way. You need an ERP application to speak to Salesforce? the answer's an API. A specific line of business application to speak to Salesforce? you guessed right, it's an API. Now you get the picture you can see just how important API's are becoming and why they're a hot topic.
API access is simple - if you have PE you don't have an API. If you have EE you do. If you need Salesforce to speak to another application, and many of you do, you need EE.
There is a fourth differentiator which is profiles. Each user gets assigned a profile which governs what they can see (there's a little more to that but that's more of an admin discussion). Depending on the size and complexity of your organisation you may need more than the 6 standard and 2 custom provided.
This post summarises the high-level discussions we have with customers. If you need more information or want to discuss specific requirements don't hesitate to call us.