Prioritize your Salesforce backlog by separating active incidents from improvements, comparing the business consequences of delay, and selecting only work that has enough clarity and capacity to finish. When something urgent enters, name the work it displaces. A longer list of priorities does not create more delivery capacity.
The difficult part usually comes after intake. Sales wants a quoting change, finance wants a different report, and an integration needs attention. Each request has a sponsor. All three sponsors would prefer Friday.
The useful output of a prioritization meeting is a short, credible delivery plan with explicit tradeoffs. Here's how to build one, using a hypothetical Salesforce backlog. These are illustrative decisions, not a client's results or a standard service commitment.
Give each request a decision, not just a priority label
A request can matter without being ready to build. Keep three decisions separate:
Importance: what business problem deserves attention, and what happens if it waits?
Readiness: is the next action clear enough to perform and verify?
Selection: can the people needed actually take it through completion now?
Those distinctions prevent a familiar failure: calling something high priority, starting it immediately, and leaving it blocked for weeks while someone decides what it means.
The Scrum Guide distinguishes an ordered product backlog from the work selected for a sprint, and describes refinement as making items more precise. You do not need to adopt Scrum to make a similar distinction in your own Salesforce operating process. This article proposes a practical workflow, not a complete Scrum implementation.
Give stakeholders plain status labels: needs clarification, ready for selection, selected, in progress, and accepted. Add a reason and next review point when work is deferred. Being in the backlog should never imply a promised delivery date.
Compare the consequences of waiting
For each candidate, ask what will happen before the next review if it is not delivered. Look for evidence: affected transactions, a recurring manual workaround, a verified external deadline, or a dependency that prevents other work from finishing.
"Sales needs this" is weaker than "approved quotes cannot reach customers because the approval request goes to an inactive user." The second statement identifies an observable failure and gives you something to test.
Use a small set of questions:
Which users, customers or transactions are affected, and how do we know?
What workaround exists, who performs it, and what risk or effort does it introduce?
Is the deadline external and consequential, or simply preferred?
What decision or dependency could stop delivery?
What is the smallest useful outcome, and who will accept it?
Numerical scoring can help compare similar work if everyone understands the inputs. It should not turn guessed revenue impact into a precise-looking ranking. An urgent service interruption, an undefined dashboard and a cosmetic change need different next actions before they need a shared decimal score.
If requests still arrive through private messages with conflicting promises, establish the intake and decision rights in your CRM governance framework first. This prioritization process depends on an agreed place where those decisions are visible.
Work through four competing requests
Imagine the following items arrive before a weekly review. The proposed decisions depend on the stated facts; change the facts and the order may change.
Quote approvals are going to an inactive approver
Several quote submissions have stalled. Sales operations provides examples, the approval owner confirms the intended replacement, and a documented manual approval route can keep existing deals moving temporarily.
First assess the live impact and use the approved workaround where appropriate. Then select a bounded repair if capacity and required testing are available. Acceptance should demonstrate that representative quotes reach the intended approver and that existing approval rules still behave correctly. The affected business owner must be available to verify it.
If there is no safe workaround and customer commitments are immediately at risk, this may require incident escalation instead of waiting for the normal queue. The business impact decides that distinction, not the requester's title.
Finance wants a redesigned forecast dashboard
Finance and sales disagree on whether the report should use current opportunity values or preserve the values committed at the start of the period. Building a new dashboard before settling that question would turn a definition dispute into rework.
Assign a short definition decision with those owners as the next action. Keep the dashboard build out of selected delivery work until the definition and acceptance examples are agreed. Clarification consumes time too, so give it an owner and capacity rather than hiding it between meetings.
An integration is producing repeated recoverable errors
The operator has a reliable recovery procedure, but the same failure is consuming attention each week. Collect the exceptions and recovery effort, confirm that transactions are not being lost, and identify a bounded diagnostic step.
Do not let a functioning workaround make this invisible forever. Compare its recurring operational cost and risk with the other ready items. The next selected action might be diagnosis, not a promise to replace the integration. Escalate immediately if evidence shows a different level of customer or transaction risk.
A page layout needs cosmetic cleanup
The proposed change would make the screen tidier, but the requester cannot identify a blocked task, material error or current usability problem. Defer it with that reason and a review point.
If later evidence shows the layout causes users to enter the wrong billing information, revisit the decision. A small interface change can matter; its size or appearance does not establish its value either way.
Make capacity visible before promising a date
Suppose the people available can currently take the quote repair through testing and acceptance, and support the forecast definition decision. That is the selected work. The integration diagnosis is a candidate for the next opening; the layout cleanup is deferred.
This is a hypothetical capacity decision, not an estimate that these tasks take a standard number of hours. The actual implementer must assess scope, uncertainty, dependencies and available time.
Include verification, release preparation, documentation and business acceptance in that assessment. A change that is configured but waiting for a finance reviewer is still unfinished work. Check the reviewer's availability before promising delivery.
The Kanban Guide defines work in progress as started but unfinished work and calls for explicit controls on how much enters the workflow. It also emphasizes addressing blocked and aging items. Apply that principle by agreeing how much active Salesforce work you can support, then making exceptions visible. There is no universal item limit that fits every org.
Before starting another request, ask whether helping an existing item finish would produce a more useful result. Otherwise, the backlog can look busy while nothing becomes usable.
An urgent request needs an explicit tradeoff
Now suppose a new issue prevents orders from reaching fulfillment. Follow the agreed incident process and establish its impact. If recovery requires the same implementer working on the quote repair, the ongoing-work owner must make that conflict visible.
The decision might be to pause the quote repair, use its approved workaround, and reset its delivery forecast while the incident is addressed. Record the pause reason and restart conditions. A paused item is still started and unfinished; moving it to a different board column does not erase it.
Alternatively, genuinely separate capacity may allow both to continue. Verify that people, permissions and reviewers are available before promising that outcome. Do not describe the incident as an extra item that somehow fits inside unchanged commitments.
Tell affected stakeholders what changed, why, and when they will receive the next assessment. A revised forecast is more useful than silently missing the original one.
End the review with a decision record
For every selected or deferred request, record the decision in terms a business owner can check:
Selected outcome and acceptance evidence.
Delivery owner and business acceptance owner.
Dependencies, uncertainty and next review point.
Work displaced by the decision, if any.
Reason for deferral, plus the evidence that would justify reconsideration.
At the next review, inspect what was actually accepted, which started items are aging, what remains blocked, and whether repeated incidents consumed the planned capacity. Close requests that are no longer relevant with the requester's context recorded. Do not keep them indefinitely just to avoid saying no.
If prioritization repeatedly fails because nobody owns those decisions between meetings, the problem extends beyond ranking tickets. The distinction between Salesforce managed services and project work helps identify which responsibilities need continuous ownership and which deserve a separate, defined delivery effort.
That ongoing connection between business decisions and system work is part of revenue operations consulting. The goal is a backlog whose next actions make sense to the people using the system, with realistic commitments that survive contact with the working week.
If your Salesforce requests keep displacing each other without clear decisions, discuss your backlog and ownership gaps with Jonathan. The initial conversation is free; detailed assessment, implementation and ongoing support are scoped and priced separately.