Salesforce Business Analyst CV example and writing guide

Use a clean, reverse-chronological format so the reader can find your recent work, dates and results without hunting for them. Two pages is a sensible target for most candidates, although one page may suit someone with limited experience. Start with your name and contact details, followed by a personal statement, selected skills, employment history, education and any relevant additional information.

Keep the personal statement to two or three sentences. State the kind of Salesforce Business Analyst work you have done, the processes or teams involved and the outcome you helped achieve. If you are new to the role, draw on a placement, apprenticeship, course project or transferable work. With more experience, lead with delivery scope, judgement and results.

In each role, connect the business need to your contribution. Relevant evidence may include discovery interviews, current-state and future-state process maps, prioritised requirements, user stories with acceptance criteria, UAT coordination or adoption analysis. Include these only when they reflect your own work, and make your precise contribution clear.

Treat the skills section as an index to evidence elsewhere in the CV. Salesforce CRM, Salesforce Service Cloud and backlog management are terms found in UK Salesforce Business Analyst roles. Requirements workshops, stakeholder management and translating business requirements also appear in roles outside London. Visualforce and Lightning Web Components belong on the CV only when you have used them and can discuss the context.

Tailor the wording to the vacancy. If the advert stresses analysis and reporting, bring forward your experience of reports and dashboards used in business decisions. If it focuses on service operations, give more space to the relevant process, testing and outcome. Do not copy every phrase from the advert.

List education and professional development plainly. Give exact titles and dates, and keep additional sections short enough that they do not push stronger project evidence off the page.

Treat every experience bullet as a small, testable piece of evidence. Start with a precise action, establish the scope, explain your contribution and finish with the result. Useful measures include time saved, transaction or case volume, number of users, defects resolved, adoption, accuracy and service performance. A modest figure that you can explain is more convincing than a dramatic number with no clear basis.

A dependable structure is: action + scope + contribution + outcome. For example: "Mapped the web-to-closure Case process across four service teams, identified seven duplicated hand-offs and helped reduce average resolution time by 12%." This tells the reader what you analysed, how broad the work was and what changed.

These figures are illustrative. Use only measurements supported by reports, project records or a calculation you can describe. When commercial data is confidential, use an authorised percentage, range or operational measure. If the outcome was not measured, quantify the scope instead: users interviewed, processes mapped, stories written, workshops facilitated or defects triaged.

Choose verbs that describe what you actually did: elicited, interviewed, mapped, analysed, prioritised, documented, translated, facilitated, wrote, validated, coordinated, tested, tracked and recommended. Be careful with broad verbs such as "delivered" or "implemented" when administrators, developers or release colleagues owned substantial parts of the change.

Discovery evidence can show how you interviewed sales managers about issues such as skipped Opportunity stages, then produced a problem statement, stakeholder list and current-state notes. Process work can trace a Case from web submission to closure and distinguish the current state from the proposed future state. Requirements analysis can show how you separated necessary approval controls from optional changes and recorded priorities, assumptions and dependencies.

For user stories, name the user group where useful and state that your acceptance criteria were testable. Testing bullets can explain whether you prepared scripts for business scenarios, gathered test evidence, maintained a defect log or contributed to a go/no-go recommendation. After release, show whether you compared login, report or feature usage before and after go-live, then turned the findings into training notes, an adoption dashboard or backlog items.

Avoid diary-style bullets such as "attended stakeholder workshops" or "responsible for Salesforce requirements". They record presence or ownership without revealing the output. State whether you resolved conflicting needs, obtained agreement, improved traceability or gave the delivery team requirements they could test. That gives the recruiter something concrete to examine.

Keep this section factual and compact. Record the exact awarded qualification or completed course, the provider and the completion date. For recent study, add one or two relevant modules or projects when they support the vacancy. Label ongoing study clearly and give the expected completion date instead of presenting it as finished.

For entrants to the broader Business Analyst occupation in the UK, the Business Analyst Level 4 Higher Apprenticeship is an optional route for gaining some relevant skills and knowledge. The Project Manager Level 6 Degree Apprenticeship is another optional route for Business Analyst role entrants. Neither route is presented here as a universal entry requirement for Salesforce Business Analyst jobs. If you completed one, use its exact title and add a short project note where it supplies useful evidence.

Your CV should demonstrate needs analysis, requirements elicitation, business case definition, requirements writing and review, flow and process diagramming, wireframing, business data analytics and problem solving. It should also show at least a basic understanding of AgentExchange, automation, collaboration, data management, reports and dashboards, CRM, platform, and sales and marketing. Prove these areas through employment or project bullets where possible; a bare list in the education section carries less weight.

If you hold Certified Administrator, Advanced Administrator or Certified Platform Developer, include the exact credential when it is relevant to the vacancy. A credential should not imply project experience you have not gained. Since 2 May 2023, the Salesforce Certified Platform Administrator certification has not been required before earning the Salesforce Certified Business Analyst certification, so do not present that former sequence as a current prerequisite.

If you do not hold a named credential, record relevant completed learning briefly and let practical project evidence carry the application. Put recent, relevant development above older study. Senior candidates can trim early academic detail once their delivery record gives stronger proof of capability.