Salesforce BA Process Flashcards
What is a case object in Salesforce?
The Case object is the main object of Salesforce Service Cloud and a Case typically represents a customer’s issue, question, or feedback and its resolution process.
What is email-to-case?
Email to case is used to automatically turn customer emails into cases, so that your agents can quickly track and resolve their issues
What is web-to-case?
The web-to-case form is used for website integration with salesforce. Similar to web-to-lead form but is mainly used by a company to manage their cases
What applications do you use to make UML diagrams?
Draw.io or MS Visio
What do you use to make mock ups if needed?
Photoshop
How do you assign a case?
Setup > Case Assignment Rules
What are Quotes in Salesforce?
Quotes represent the proposed prices of your company’s products and services. You create a quote from an opportunity and its products.
What is a Salesforce Business Analyst?
Salesforce business analyst is a project-based, business-improvement role. Business analysts help guide businesses to improve business processes and efficiency in Salesforce. They elicit, document, and analyze requirements around business challenges, and then produce data-driven solutions
UML diagram used to show current process flow?
As-is diagram
What are some of your roles as a Salesforce BA
My main roles as a SF BA include consistently demonstrating excellent communication skills, documenting requirements, analyzing information, facilitating solutions, implementing solutions, and testing after implementing
Some of my roles as a SF BA included Gathering requirements and leading the whole requirement documentation process, creating and prioritizing user stories and epics, creating UML diagrams, designing mock ups, analyzing, translating, and defining data, remaining on high alert to facilitate communication between stakeholders and development team answering any questions or points of confusion that may develop, reviewing test plans and test cases, using my knowledge of the CRM to produce high value solutions and approaches to streamline workflow processes
How do you gather requirements?
I like to take a deep dive into current process workflows, look into background and past information about the business and the project, and speak to subject matter experts and stakeholders. I ask a series of who, what, where, when, and why questions that are relavant to the stakeholders request. I ask as many questions as I can think of to make sure I have a clear understanding of what they need done so that I can be well equip to come up with the best solution possible. The more information I have, the better the analysis
I am very personable so this process is more of a conversation than an interview
What is an Enterprise Analysis?
an analysis of the organization’s structure, including who reports to whom, and the functions and interactions of departments within the organization. The information you gain here helps your team successfully collaborate and communicate
What is a Strategy Analysis?
An analysis of how you will meet the business need
How do you conduct an Analysis for a project?
First, I gather the requirements, then I observe and lay out the current state of the business with an AS-IS diagram and define the future state and the objectives we are trying to reach with a To-Be diagram. After that I conduct a gap analysis to outline and determine the scope of work required to achieve our desired state. As well as recommending the highest value approach to getting there and potential risks.
Who is a stakeholder?
A stakeholder is anyone who has an interest in, or may be affected by, the issue under consideration.
What are some different elicitation methods?
Brainstorming, focus groups, requirements workshops, surveys/questionnaires, interviews, interface analysis
Ba communication examples:
Communicate the stakeholder’s needs to the project team
Ensure that, at the conclusion of the project, those needs have been met
Break down the barriers to communication—such as time, attention, expectation, or language—that can occur between stakeholders and developers.
Tips for Engaging Stakeholders to Achieve Project Goals
Communicate by Making It a Conversation
Share How You Can Help
Get Commitment for Next Steps
Acknowledge your respect for their time
Develop Relationships
Verbal Communication Tips
Speak clearly and loudly.
Choose your words carefully.
Use an appropriate tone.
Consider your audience.
Respond appropriately
Non Verbal Communication Tips
Eye contact
Personal space
Posture and movement
Openness of body
Types of documents Business Analysts use/compile
Glossary of terms
RACI chart
Interview and elicitation records
Stakeholder analysis
User stories
Use cases
Business analysis plan
Current state analysis
Scope statement specification
Functional requirements specification (FRS)
System requirements specification (SRS)
Gap analysis document
Change request logs
Wireframes and other visual documentation
Test plans, test cases, or user acceptance test plans
Change management
Presentation Methods:
Formal Documentation - This format is usually based on an organizational template and can include text, matrices, or diagrams.
Informal Documentation - This format may include text, matrices, or diagrams that are not part of a formal organizational process.
Presentations - This format is best for providing a high-level overview of goals, solutions, or information to support a decision.
I like to use outline, flow diagrams, PowerPoints, and dashboards
What is a BRD?
The BRD is the project bible. The BRD includes all the requirements of the project, key stakeholders, the project’s objective, expected timeline, scope of work, estimated costs, and potential risk.
Business Requirements Document - requirements for the project (Change initiative) are described from the customer’s perspective.
What is a user story?
a user story helps translate technical requirements into easy-to-understand ideas. User stories are simple descriptions of a feature told from the user’s point of view. As it relates to a Salesforce business analyst, user stories explain the roles of users in a Salesforce system, their desired activities, and what they intend to accomplish.
User stories are helpful because:
They are easily digestible for developers bc they’re being written from a high level
They enable collaboration amongst the team - we can work together to decide how best to serve the user and meet the goal
Help focus on how a project or specific functionality can deliver value back to the end user
Saves time when prioritizing the development/implementation of requirements and functionality.
Avoid restrictions that occur when specification details are defined too early on
Deliver features/products that users actually need
Focus on how a project can deliver value back to the customer/end-user.
.
Increase collaboration and transparency within the project team.
.
Assist in testing solutions.
Parts to be included in a user story:
Who: From whose perspective (aka user persona) within Salesforce will this user story be written?
What: What goal will be accomplished or implemented within the Salesforce org as the result of the user story?
Why: Why does the user need the Salesforce functionality or feature outlined in the user story?
Outline: As a < who >, I want < what > so that < why >.
User Story Example: As a customer care representative, I want to take ownership of new cases and communicate with customers so that I can provide high-touch customer experiences.
What is a user story- writing workshop and at what point in the development process is it usually held?
It’s recommended that a user story-writing workshop is held near the start of a project. Story-writing workshops are organized to include the project team: product manager(s), developer(s), admin(s), UX designer(s), users, and so on. Participants brainstorm to generate story ideas.
What is acceptance criteria?
Acceptance criteria are a set of statements, each with a clear pass/fail result, added to a user story. Put simply, acceptance criteria specify conditions under which a user story is fulfilled. They should be expressed clearly, in simple language, without any ambiguity about the expected outcome.
Why are acceptance criteria helpful?
Clarifies the scope for the project team
Assists the development/implementation team
Ensuring testers know what should be tested
TRUE OR FALSE: Does every user story need acceptance criteria?
TRUE: every user story should have at least one acceptance criteria. Each criteria should be independently testable and answered with either a true or false.
What is the format for writing acceptance criteria?
Acceptance criteria can be formatted as if/then statements.
what should good acceptance criteria focus on?
Acceptance criteria should state intent, but not a solution. Think of the what, not the how.
Acceptance Criteria example:
User Story Example: As a customer care representative, I want to be able to take ownership of new cases and communicate with customers so that I can provide high-touch customer experiences.
Acceptance Criteria: If on a case page, then the email customer feature is accessible.
User story acronym for successful user story
INVEST
A successful user story is:
Independent: User stories should be independent and not overlapping in concept with another user story.
Negotiable: A user story is not a contract. A story is an invitation to a conversation. It captures the essence, not the details.
Valuable: The user story needs to be useful to the end user. If a story does not have value, it should not be created.
Estimatable: A successful user story’s timeline can be estimated. An exact estimate is not required, but just enough to help prioritize and schedule the story’s development/implementation.
Small: Most effective user stories are small. Smaller user stories tend to get more accurate timeline estimates. Remember, the details can be elaborated through conversations.
Testable: A good user story is testable. For a successful story, anyone on the project team can look at the user story and say, “Yes, I understand this user story so well that I can write acceptance criteria for it.”
Mistakes to Avoid when writing a user story:
The project team didn’t engage in story writing.
The who of the user story is an undefined user.
The why in the user story is feature specific.
The acceptance criteria is too vague.
The user story was assigned to the implementation team without a team discussion.
What is an executive summary?
An executive summary is a brief summary of your project plan
What does an executive summary include?
Reserve the data analysis and more involved details and charts to the project plan itself. Instead, focus on a summary of the project plan. It should look something like the following:
Includes a one- to two-sentence descriptive summary of the overall plan.
Identifies the problem.
Explains your solution.
Identifies who needs to act and what they need to do.
Next up, creating your outline.
