Your Salesforce CRM is a critical asset that supports your sales, marketing, and customer service teams. To get the full value from its capabilities and drive business growth, you need a reliable partner who can keep its performance, security, and ongoing improvement on track.
Oblytech specializes in Salesforce support and maintenance services, providing proactive monitoring, issue resolution, and continuous optimization to maximize the value of your Salesforce investment.
Salesforce support is often bought as a single line item, but the right model depends on how the org is used. An org with a stable configuration and a small number of changes each quarter needs a different arrangement from an org that changes weekly, runs several integrations, and serves teams in different time zones. The first step is to describe the type of change the org receives, because that determines whether the support model should focus on fault response, planned change, or both.
| Support model | Fits when | What the buyer must still provide |
|---|---|---|
| Fault response only | A stable org with an internal administrator who makes routine changes | A reporting route for faults and a named internal contact |
| Fault response with planned change | Regular enhancements that need design, testing and release | A prioritized change backlog and sign-off for each release |
| Ongoing platform stewardship | Several integrations, shared objects and frequent releases | Access to requirements owners and a budget that reflects continuing work |
Every change to a live org is a release, whether it is a field, a flow, a report or a permission. A release process should state where the change was built, how it was tested, who approved it and how it can be reversed. Teams that treat small changes as informal often find that a minor report change has broken a dashboard that a manager uses every morning, or that a permission change has removed access for a whole team.
Release frequency should be agreed rather than assumed. A monthly release window gives the business time to review changes and gives the support team time to test them. Emergency changes are sometimes necessary, but they should be recorded, reviewed and merged back into the normal release process so that the next release does not undo them.
A support arrangement that depends on one external person is fragile. Knowledge transfer should be built into the service from the start: the support team writes down the reasons for each standing configuration, records the location of each automation and integration, and walks an internal administrator through the common fault patterns. The aim is that a new internal administrator can understand the org within a reasonable period, without needing the original builder in the room.
Permissions drift over time. Users change roles, temporary access is granted and never removed, and integration users accumulate fields they once needed. A support service should include a regular access review in which the business owner confirms who should hold each permission set, and the support team removes access that is no longer justified. The review should also check connected applications, login settings and the integration users created for each flow.
Security findings should go into the release process as normal work items. A finding that is recorded but not scheduled is effectively accepted risk, and the record should show who accepted it and until when.
Response commitments should describe what the team will do, how urgency is judged, the channels that are monitored and the hours that apply. They should be written in a form that the business can check after an incident. A commitment that cannot be measured from the ticket record is hard to enforce for either side. Before signing, ask how the time to acknowledge and the time to resolve are recorded, who decides a priority, and how a disagreement about priority is settled.
| Commitment element | Question to ask | Evidence to request |
|---|---|---|
| Acknowledgement | How is the start time recorded | A sample ticket showing the timestamps |
| Priority | Who sets priority and on what basis | The priority definitions in writing |
| Resolution | What counts as resolved | The closure standard and reopen rule |
| Coverage | Which hours and channels apply | The support calendar and escalation contacts |
A useful support review asks whether the same faults recur, whether planned changes arrive on time, whether the internal team is taking on more of the work, and whether users trust the platform. Ticket volume alone says little. A falling volume may mean fewer faults, or it may mean users have stopped reporting them. Pair the ticket data with a short user survey and with a review of the change backlog, so that the picture is complete.
A support model assumes that someone inside the business can take decisions between visits and tickets. Ask how many hours a month the internal administrator can realistically give to the org, what other systems they own, and who covers them when they are away. If the administrator is the only person who understands the org, the support model must include deliberate cover, otherwise every incident becomes a dependency on one person.
Salesforce operates the underlying platform, but a support arrangement still needs a recovery plan the business has tested. The plan should state which data is exported regularly, where the exports are kept, who may request a restore and how a restore is checked against the business process. Support teams should also confirm which recovery actions require a request to the platform and how long those take, because a restore discussed in a meeting is not the same as one that has been rehearsed.
Support work tends to accumulate workarounds. A field added to fix a reporting gap, a flow that patches a data quality problem upstream and a permission granted for a one-off project all remain long after their reason has passed. Include a periodic review of standing changes in the support plan, asking whether each one still serves the process it was built for. Retiring a workaround can be among the most valuable changes a support team makes, because it reduces the surface every future release must test.
Often yes, for fault cover, release testing and specialist work the internal team does not do often. The question is which of those the administrator cannot cover without risk.
Through a defined emergency route with a named approver and a follow-up review. The change should then enter the normal release process so it is not lost.
Review the inventory, the fault log and the change backlog. The renewal should reflect what the org needs now, not what it needed when the support began.
It can, but each cloud and integration should have its own owner and its own release notes so that a change in one area does not surprise another.
If your org is changing faster than your internal team can review it, the release frequency, the integrations and the fault pattern are the three facts that decide which support model fits. The configuration and customization page covers Salesforce configuration and customization work, and the ServiceNow support and maintenance page lists the equivalent support services on the other platform.
A Salesforce support and maintenance contract starts with a baseline review of the org as it stands, before the support team works any ticket as a fix. The review records what exists, what is fragile, and who is allowed to change what. If a previous partner built the org, the review is also where you check how much of that knowledge actually arrived. Where the handover is still open, how to plan a clean knowledge transfer covers the steps.
The baseline usually runs in a set order. The inventory comes first: custom objects, fields that nothing reads, flows and approval processes, the reports managers open each week, and the connected apps and integration users behind them. The permission review comes second, because an org built over several years often holds permission sets granted for a project that ended long ago. The open-fault list comes third, drawn from the internal team’s notes and from any tickets raised before the contract began. Data problems found along the way, such as duplicate accounts, belong in a data quality review rather than in the fault queue.
The fourth step is the one most often skipped: naming the load-bearing automations. A flow that sends a renewal notice, or a validation rule that stops bad data at entry, is a dependency for someone. Each one needs a named owner, and changes to it should be tested before release. Settle who owns each integration at the same point, using the approach in integration architecture with defined ownership.
The output is a short document with three parts, each with a clear decision owner.
| Baseline output | What goes in it | Who decides |
|---|---|---|
| Leave alone | Items that look unused but have a purpose, such as a field that feeds a monthly export | The business owner of that process |
| Fix in the first release | Faults with a known cause and a low-risk fix, such as a report filter returning another team’s records | Support lead with the internal administrator |
| Needs a decision | Changes that alter how a team works, such as retiring a status value | The business owner, in writing |
Avoid turning the baseline into a large clean-up programme. Several problems that look urgent in week one turn out to be deliberate. A short question to the owner costs far less than reversing a change that broke a monthly export.
Salesforce support and maintenance is the ongoing service that keeps a live org running. Faults get diagnosed and fixed, planned changes are tested before release, and the platform stays secure as it changes. Buy it when the org already does its job and the problem is keeping it that way. Do not buy it expecting a support queue to repair a process or data model that was wrong from the start; that work keeps coming back.
The simplest test is to sort your open problems into two piles. The first holds faults with a known shape: a report returns records it should not, a flow fails for one region, a user cannot see a field they need. That is support work. The second holds requests that change how the business sells or services customers, such as a new approval route, a second pipeline for a product line, or a rebuilt object structure. That is implementation or consulting work, and it needs a design decision signed off before anyone builds.
| Question | Support and maintenance | Implementation or redesign |
|---|---|---|
| Typical trigger | Faults, routine changes, scheduled releases | A new process, object or integration, or a design that is failing |
| What you receive | Resolved incidents, tested releases, a fault log | A configured design the business has accepted in writing |
| Who sets scope | The support lead working with the internal administrator | The business owner with a named design authority |
| Cost of buying the wrong one | Recurring faults that never receive a structural fix | Build effort spent on a design nobody adopts |
The common mistake is asking the support team to patch a design problem every sprint. The patches pile up as workarounds, and each future release has to test all of them. If the same kind of fault returns every month, the design is usually the cause. Log it, give it a decision owner, and send it down the redesign route instead of the queue.
If most of your open list sits in the second pile, begin with the Salesforce implementation service, which suits an org whose process is still unsettled. If you are unsure which pile dominates, a strategy roadmap can help you order the requests. Once the design is stable and the workload is steady, a dedicated Salesforce delivery team is a sensible way to staff ongoing support.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.