In today’s competitive landscape, customer relationships are more crucial than ever. Salesforce, a CRM platform, provides the tools to nurture these relationships, streamline sales processes, and drive sustainable growth. However, to get real value from it for your business, it’s essential to configure and customize the platform to match your unique processes, workflows, and objectives.
At Oblytech, our Salesforce Configuration & Customization services go beyond basic setup. We look closely at your business requirements and shape Salesforce to fit your particular needs. From improving lead management and sales automation to creating custom objects, fields, and workflows that connect cleanly with your existing systems, we help your business get more from Salesforce.
We begin by conducting in-depth discussions with your team to understand your business processes, pain points, and goals for Salesforce. We’ll explore your current challenges, identify areas for improvement, and envision how Salesforce can best support your unique workflows and objectives.
Based on the insights gathered during the discovery phase, we create a detailed solution design that outlines the configuration, customization, and integration requirements to meet your specific needs. We collaborate closely with you to ensure that the proposed solution aligns closely with your business vision and goals.
Our experienced Salesforce consultants and developers configure and customize Salesforce so it fits your workflows and data structures. We use our expertise to tune standard features, create custom objects and fields, and build automation workflows that streamline your processes.
We rigorously test every aspect of the configured and customized Salesforce environment to check functionality and performance. Our QA team conducts comprehensive testing, including functional, integration, and user acceptance testing, to identify and address any potential issues before deployment.
We deploy your customized Salesforce solution to a secure and scalable environment. We also provide comprehensive training to your team, helping them use Salesforce well and with confidence. Our training programs cover all aspects of the platform, from basic navigation to advanced features and customization.
We understand that your business needs evolve over time. That’s why we offer ongoing support and maintenance services to keep your Salesforce instance up-to-date, secure, and optimized for your changing requirements. We also provide continuous improvement recommendations and proactive optimization to help you keep getting value from Salesforce.
Configuration means changing what the platform already offers: picklist values, page layouts, record types, validation rules, permission sets, reports and dashboards. Customization means adding something the platform does not provide out of the box, such as a new object with its own lifecycle, a field with unusual behavior, or code. The distinction matters because each step up the ladder costs more to build and more to keep working. A requirement that a validation rule and a page layout can meet should not become a custom object simply because it was described that way in a workshop.
The useful question for any request is which is the least powerful tool that meets the requirement without producing a workaround. That question should be asked before design begins, and the answer should be recorded so that the next administrator understands why a particular field or component exists.
| Request as people describe it | Usually a configuration answer | When customization is justified |
|---|---|---|
| Sales reps need to see different fields for different products | Record types and page layouts with a clear field set for each | Dynamic components only if layouts cannot separate the needs cleanly |
| Managers want to stop incomplete records moving forward | Validation rules tied to the stage or status | Code only where the rule depends on data held outside the record |
| A team tracks a process the standard objects do not describe | Check whether an existing object with extra fields is enough | A custom object when the process has its own lifecycle and reporting needs |
| Users need one screen to see data held in another system | Related lists and reports where the data already lives | An integrated component, designed with the integration owner |
Every custom field, record type and permission set adds a decision that someone must maintain. Field names drift, and fields that hold similar data accumulate under different labels. Page layouts diverge between profiles. Permission sets are granted to solve one request and never removed, so access slowly exceeds what anyone intended. None of these problems breaks the org on the day it is changed, which is why they go unnoticed until two reports disagree or an auditor asks who can edit a particular field.
A configuration standard can prevent much of this. It should set the naming pattern for fields, the test for when a new record type is justified, the review step for new permission sets, and the owner who approves changes to shared objects. The standard does not need to be long. It needs to be read before every change, and it needs to be kept in the same place as the rest of the org documentation.
Customizations need an environment path. Changes are built in a development or sandbox environment, tested against realistic data, reviewed, and then deployed to production in a controlled way. Teams that skip this path tend to discover that a field change in production breaks an integration nobody remembered, or that a layout edit hides a field a support team relies on. Where source control is used, the repository becomes the record of what changed and why. Where change sets are used, the description must state the business reason, not only the list of components.
Customization also carries a running cost. Custom code must be reviewed when the platform releases new features, custom fields must be checked when integrations change, and components built by a departed consultant need a new owner. Before approving a customization, ask who will maintain it after go-live, what happens to it when the platform changes, and whether a standard feature is likely to make it unnecessary within the next planning cycle.
Most of these requirements are first gathered during discovery, which is described on the needs assessment and discovery page. A proposal that skips that step often moves requirements gathering into the build phase, where each change tends to cost more and be harder to test.
| Proposal element | Good sign | Warning sign |
|---|---|---|
| Scope of change | Components listed by name with a business reason | Broad phrases such as bespoke configuration throughout |
| Testing | Profile and permission cases included | Testing described only as user acceptance at the end |
| Ownership | Named internal administrator and developer | No owner after release |
Test with the people who will use the screens, using their own scenarios rather than a scripted tour of every field. A sales rep who tries to convert a deal on a phone between meetings will find problems that a tester on a large monitor never sees. Include a profile for each group that uses the layout, because page visibility, field-level security and record-type assignment interact in ways that look correct in one profile and broken in another. Record the results against the requirement each scenario covers, so that a failed test points back to a decision rather than to a vague complaint.
Retirement is part of configuration hygiene. A field that no report reads, a record type with no active records and a permission set nobody has granted in a year are candidates for removal. Removal needs its own check, because a field may still feed an integration or a scheduled export that the administrator has not seen. Deactivate first, watch for a full reporting cycle, then delete. Keep the removal in the change record so the reason is available when someone asks why a field disappeared.
Usually it is cheaper to build and to maintain, but a poor configuration that produces a messy org can cost more over time than a well-designed customization. The comparison should be about total ownership, not only the build effort.
There is no fixed limit that applies to every org. The warning signs are fields nobody can explain, duplicated fields holding similar data, and reports that depend on fields no one has reviewed for a long time.
Where possible, yes. A shared sandbox that everyone edits makes it hard to tell which change caused a problem and makes test results unreliable.
Review each customization against platform releases. Some custom work becomes unnecessary and should be retired, while other custom work needs small adjustments to keep working.
Bring the screens your team uses most and the decisions they cannot make today, and you can contact Oblytech to discuss them.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.