I recently helped a Startup implemented Salesforce as its "New" CRM System, the implementation was half-baked with glaring issues when I took over, with the two-week deadline fast approaching, I worked day and night together with the Business Analyst (BA) from this Startup, fortunately the implementation was successfully delivered on time and on budget, but it was a roller-coaster ride for the BA and me.
If your company is a Startup that is getting ready to implement Salesforce or migrate from another CRM system to Salesforce, based on the projects that I was involved in during the past few years as a Salesforce Consultant, and from my work at four Startups (Splunk-IPO in 2012, Gigamon-IPO in 2013, Big Switch Networks-Acquired in 2020, Sauce Labs-Pre IPO) as the Salesforce Technical Architect/Director of Business Applications, I would like to share my Salesforce Implementation 101 for Startups with you, hope it helps.
Step #1 - Organize a Project Team
You will need a minimum of three members on this Project Team.
Executive Sponsor: A senior leader in an organization who is responsible for the success of a project.
Business Analyst: A person who processes, interprets and documents business processes, products, services and software through analysis of data.
Salesforce Architect: A certified hands-on Salesforce Architect who helps design and deliver solutions using Salesforce products.
Step #2 - Create the Process Flow Diagram
A Process Flow Diagram can clearly outline the tasks and events involved in a process, making it easier for the project team to understand and work together.
For example, a Salesforce Lead to Opportunity process flow diagram typically starts with "Lead Capture" (from marketing or other sources), progresses through "Lead Qualification" where the lead is assessed for potential, then moves to "Lead Conversion" where the qualified lead is transformed into an Opportunity, followed by various "Opportunity Stages" (like Needs Analysis, Proposal, Negotiation) until finally reaching "Closed Won" or "Closed Lost" depending on the sales outcome.
The Model-View-Controller (MVC) architecture is a software design pattern widely employed in various frameworks and platforms, including Salesforce. Based on your Process Flow Diagram, follow the Model-View-Controller (MVC) design pattern to organize your Salesforce implementation into three interconnected components: the model, the view, and the controller.
The Model component demonstrates the data and business logic of an application. It is responsible for managing the application’s data, processing business rules, and responding to requests for information from other components, such as the View and the Controller.
Things to consider when designing the model in your Salesforce implementation:
Adopt the standard data objects as much as you can than creating your own custom data objects from scratch.
Add custom fields to the data objects if needed, analyze the source data for the data type & data size first.
Understand the Formula Field. The value of the formula fields are determined at read time, as they are not stored in the database. You can’t roll records up with a formula field, nor reference child objects.
Use Global Picklist Value Sets to share values across objects and custom picklist fields, and to restrict the picklists to only the values that you specify.
For the Yes/No selection, consider using the Checkbox field rather than a Yes/No picklist field.
Use Reverse Engineering, see what's in your existing reports/dashboards and what you would like to see in the new reports/dashboards, make sure the data placeholders (i.e. fields) are there in Salesforce.
Step #3.2 - Design the View
The View component displays the data from the Model to the user and sends user inputs to the Controller. It is passive and does not directly interact with the Model. Instead, it receives data from the Model and sends user inputs to the Controller for processing.
Things to consider when designing the View in your Salesforce implementation:
If a field from another object is only for viewing purposes (not for reporting purposes), there is no need to create a formula field, just add the field directly to the record page.
If there are a lot of required data that you would like to collect at different stages of a record's lifecycle, consider having multiple custom Lightning Record Pages and assign these record pages to different record types. Use the Field UI Behavior Required settings on the lightning record page to validate the existence of data over creating lots of Validation Rules.
Step #3.3 - Design the Controller
The Controller component acts as an intermediary between the Model and the View. It handles user input and updates the Model accordingly and updates the View to reflect changes in the Model. It contains application logic, such as workflow automation, input validation and data transformation.
Things to consider when designing the Controller in your Salesforce implementation:
Flow and Apex are the preferred no-code and pro-code solutions for record-triggered automation on the Salesforce platform. The table below shows the most common trigger use cases, it provides solutions recommendations for various triggered automation use cases along with the rationale for those recommendations.
Use the Flow Trigger Explorer or a Apex Framework to manage your record-triggered automations, especially when it comes to the execution order of these automations.
Track the deliverables, bugs and change requests systematically and communicate the changes thoroughly with all stakeholders. Seek the balance between Scope-Time-Cost without risking the Quality.
Do the Design and Unit Testing in the Developer Sandbox, deploy the Change Sets to a separate environment (e.g. the Partial Copy sandbox) and conduct the UAT (User Acceptance Testing) in this environment.
Don't use the out-of-the box User Profiles, create your own custom profiles (e.g. "My Company Name - Standard User") by cloning the out-of-the box user profiles (e.g. "Standard User").
Create Permission Set to extend users’ functional access without changing their profiles. e.g. create a permission set with the Export Reports permission checked, and you can then assign it to individual users.
Create a dedicated user login for integration with other Business Solutions. Securely store the user's Password and the Security Token. Create a "Password Never Expires" permission set and assign it to this user.
Set the Object Permissions and Field Permissions through the user profiles and permission sets, use the Sharing Rules to extend the Record Level Access based on the record owner or other criteria.
Configure the Einstein Activity Capture (EAC) if needed. Let Einstein help keep data between Salesforce and your email and calendar applications up to date. EAC is especially helpful when you want to track the Meeting Dates in Salesforce for your KPI reports and dashboards.
Create training docs and videos, train your users on how to use Salesforce for their roles.
Step #5 - Going Live
Set up the Domain of your Salesforce Production org.
Use the Data Import Wizard or the Data Loader to import accounts, contacts and leads. Use the Data Loader to import Opportunities.
Activate the integration with other Business Solutions.
Create users and assign them to the custom user profiles you created.
Assign the permission sets to individual users.
Build and run reports and dashboards. Expect the unexpected, seek truth from fact, dirty and bad data is going to be there. Validate and fine-tune your Salesforce implementation from the real-time data feeds in your production org.
It can take at least a week or two for things to stabilize after the go-live. Be prepared for it.
What makes a successful Salesforce implementation at Startups?
Get the right members on your Salesforce implementation project team.
Set realistic goals.
Communicate with all stakeholders regularly.
Developing a change management strategy to ensure users adopt the system.
Anticipating and mitigating risks to the implementation timeline, budget, and scope.
Why should you have a Salesforce Architect on your project team?
A Salesforce Architect is a technical expert who designs and delivers Salesforce solutions to help businesses succeed. They are responsible for:
Recommending solutions: Salesforce Architects recommend the best solution for a set of requirements and explain the trade-offs involved.
Bridging the gap: They act as a bridge between business problems and technical solutions.
Ensuring scalability: They ensure that the solution is scalable, secure, and strategically aligned with the organization's IT framework.
Providing technical guidance: They are the lead technical resource for delivery teams and project stakeholders.
One Last Tips
For some of the Salesforce products (e.g. CRM Analytics), Salesforce normally would offer a 30-day free trial by signing a $0 order form. Take advantage of the free trial if you would like to see how those products work in your Production org with your Production data.
About the Author:
I am a Tableau CRM Analytics Ambassador, a Salesforce Certified Application Architect and a LinkedIn blogger. Please follow me Paul Liu on LinkedIn if you are interested in reading my future blogs about Salesforce and CRM Analytics. I also have published 17 apps on the Salesforce AppExchange including five "Five Stars" Apps for Opportunities, Orders and Quotes.
