Table of Content
Salesforce CRM solution is recognized as the world’s #1 business platform, and one of the most powerful tools designed to increase sales and enhance customer support. Its wide range of extendable features would suit most of today’s complex business needs. But how can you safely transform your business processes into Salesforce and convert your business requirements into user stories? Here below we address these questions and provide various examples of user stories along with their key features. We emphasize how you can standardize and perfect the process of implementing and upgrading Salesforce solutions via recommended developmental and testing flows. We also cover how you can pre-analyze the impact of Salesforce Customizations on existing features for a smooth release.
If you know Salesforce, you know that these upgrades are needed on a continuous basis, given the new features released by Salesforce every quarter to meet your ever-changing business needs. And so you know you need to be smart about implementing them.
Convert Your Business Processes Into User Stories
Salesforce essentially helps you take your business to the cloud platform. And in doing so, it can help you meet and/or even surpass your sales, service, marketing, and engagement goals. You will most likely have a large number of tasks or processes that you want to be enabled in Salesforce. The way to properly manage this is to divide each functionality or task into various small units of work called “user stories.” You can then assign these stories to your admins/developers and watch your business quickly come to life within the Salesforce platform.
Let’s take a look at what these “user stories” entail.
Key Features Of User Stories
- A user story tells us who is going to do what in order to support each business function.
- A user story describes the functionality that an end user will need in non-technical language.
- A user story is a clear point of reference as to whether or not you achieved a needed functionality. It should also contain acceptance criteria.
- Most Salesforce projects run agile methodology, and user stories provide a solid foundation regarding what to do in each sprint and how to track them concretely.
- One or more user stories can be linked. This means that they must move to the next stage together, or functionality may break during integration.
- A user story is a concrete unit of work; it has an owner and can track efforts as well as start and end dates.
- Test cases can be associated to a user story with software tools in order to verify user stories are working as expected.
———-
You might also like our blog
Salesforce Picklists and Other Objects: Top Tips for Making Changes
———-
So what are some common business use cases that can be converted into user stories?
Sales Cloud User Stories
As a Sales Manager, you can be notified whenever someone in your team creates an opportunity that’s over $10,000 and take ownership of any opportunities that are over $1,000,000.
As an Account Director, you can share key details regarding your accounts to the sales team such as Key Contact, website, and the number of employees.
Service Cloud User Stories
As a Live Agent, you can chat with customers right on your website and resolve or transfer a customer’s request immediately.
As a Service Agent Manager, you can expedite cases not acted upon within a certain period of time, as defined by the customer’s SLA.
Combined and Complex User Stories
As a Marketing Manager, you should be able to add customers to a targeted campaign for an “exchange of product” program, if the customers have recently logged a support case for a product defect.
This example above highlights how sometimes your business use cases may overlap multiple clouds (Marketing and Service in this example).
Map User Stories Into Tasks via S/W Management Tools
You can typically convert these stories into individual tasks and assign these tasks to the relevant developers or admins. And you can use project management tools to create these tasks, group them into projects, and gain visibility into all developmental activities over the course of a sprint. When assigning a task, you establish ownership and can also set other parameters such as due dates and efforts required to complete it. Then you create sprints, which decide which tasks are to be completed in the current sprint release.
When you see a combined view of user stories at the sprint level, you can see what is going to happen in the release. This overall picture can help you plan release dates, analyze release impacts, and determine accountability. You can easily lose visibility if your organization is implementing multiple Salesforce changes with its business clients. With this visibility, we can do better planning of ongoing sprints/releases, which will mean a better delivery experience, leading to a happier customer.
The Concept of Requirement Scoping
Now let’s take a look at a useful new approach to Salesforce development. Once your project is established, you can create individual requirements/tasks/stories. In requirement scoping, you add all the changes you might need to perform these tasks. These can include declarative features, such as validation rules, workflow rules, formulas, territory management, profiles, and page layouts. Programming features such as lightning components can also be added for a more complicated change.
The components listed in the requirement create the scope of your requirement. Now we can analyze how one requirement might interfere with another if they have the same components in their scope. In such cases, it is best if both task assignees work together on a solution. If not, one developer can easily override or conflict with the other’s work.
Salesforce ForeSights’ software enables you to create these scoped entities so that you can generate an automatic summary report of impacted Salesforce components both declarative and apex-based, and view dependency relations. ForeSight is also smart enough to identify indirect scopes of the same requirement by analyzing code and metadata in a background process. For instance, if you are changing a field type, the software can tell you in which reports, validation rules, etc. the field is already being used, which might create issues in those functionalities when the change is made.
Implementing in a Sandbox Org
It is highly important to complete your assigned tasks and requirements in a test/sandbox org prior to moving it to production. Given the power and ease of Salesforce implementations, many admins typically move to building things directly in production. This is not an advisable practice and can have severe consequences. You can lose reliability if the solution is not thoroughly tested, and you might inadvertently impact an already running functionality if you have not properly analyzed dependencies. There are a number of potential issues that can pop up when you develop directly in a production environment, all of which are better to avoid.
For larger organizations, we typically enforce a chain of orgs:
- Developer Org: Multiple developer orgs for developing individual requirements.
- Integration Org: Changes from multiple developer orgs are synced into an integration org. Developer testing is done here to ensure things don’t break due to changes in one org affecting another.
- QA Org: This is where functional testing takes place. If any functionality is not working as expected, it is sent back to dev for improvement, and the cycle reiterates.
- UAT Org: User-acceptance testing is done by end users for whom the functionality was built. Once they are happy, the change can be marked as ready for production.
- Production Org: After UAT, deployment can occur to production/live environment.
Depending on your org’s complexity and the size of your development team, you might add or remove various stages. Typically larger and more complex organizations have a longer release chain.
———-
You might also like our blog
Salesforce Sandbox: Managing Changes in Production
———-
Impact and Risk Analysis
To ensure your new requirements don’t create issues for any functionalities already up and running, you need to do a complete risk analysis of your onboarding changes. Before explaining how that would work, let’s look at a couple of examples of how a new process might inadvertently break another without you realizing it:
- You add a validation rule to make entering a street address mandatory while creating/editing contacts via the Page-Layout. But you had also previously configured an app-exchange package to create contacts automatically by syncing with Gmail contacts. Now this syncing process will fail, as Gmail contacts might not have a physical address.
- You create a process builder to auto-populate a contact field from a related record in Salesforce. But you failed to realize that a contact trigger already exists. With this new change, the trigger will now run twice due to the field update in process builder, which may then lead to unexpected results such as performing calculations twice or making multiple API calls.
Now these are just high-level examples. To make matters worse, both the validation rule and process builder could have been created by our super-fast admin directly in production, resulting in other critical issues and substantial losses to your business.
It’s a very difficult task to analyze these malfunctions manually, as you might have already built tens of thousands of functionalities in the widespread Salesforce ecosystem. It’s simply very challenging to review them manually one-by-one. Luckily, we can use automation tools such as Panaya ForeSight for this. When we create scoped entities in ForeSight and add all the components needed for each change, the software automatically calculates all the places where that component is used and shows us the list. It can also find out the indirect components affected by the change.
By getting this information beforehand, developers will make fewer mistakes, thereby eliminating the risk of breaking any functionality already in existence. ForeSight also calculates how frequently a particular component is used and thus how critical it can be if a problem occurs.
———-
You might also like our blog
Salesforce Testing: 5 Tips for Functional and UAT Testing
———-
Importance of Testing
Testing is critical to the health of an application. It uncovers potential issues and ensures software that runs smoothly. In Salesforce, where most implementations are customer-centric, proper testing is essential to ensure compliance, availability, and reliability of the solution.
You have to have a detailed test plan against each new requirement that you are planning to build. Each test plan typically contains various test cases to ensure that all of the acceptance criteria for each requirement are covered. You need to cover both positive and negative scenarios, boundary conditions, and explicit test cases to check if any existing functionality could be impacted. In sensitive orgs, it is not uncommon to have testing efforts that are far greater than the efforts put into development.
One feature of ForeSight is the ability to associate manual test cases to individual requirements. It also has the ability to create automated tests for requirements based on the components affected. These tests can be marked as passed, failed, or unexecuted. All of this is then transmitted into the risk summary graph and risk cockpits. If test cases pass and all is green, you can be far more confident about your release and deployment.
Summary
So yes, you can start applying Salesforce to your business processes. And given the variety of features offered by Salesforce, most business processes can be driven onto the Salesforce platform fairly quickly. In this post, we discussed the ways in which Salesforce can act as a medium for implementing your business processes and the need for requirement scoping so that you can track what changes were executed for each feature enabled. We discussed proper risk analysis so that you can avoid inadvertently corrupting an existing functionality when implementing a new one. And we covered the importance of testing and how you can ensure your implementations are smooth and pleasing to the customer.
By following the above guidelines and using proper tools such as ForeSight, you can be more confident that you are safely applying Salesforce to your business processes for smart, efficient results. Read our guide on 5 Tips for Easy Salesforce Changes and Customizations to learn more.