# Salesforce for Medium Businesses | SynconAI > Salesforce for scaling teams: governance, visibility and automation. Fix the sprawl, name an owner, and settle the edition question before integration bites. Publisher: SynconAI Source: https://synconai.com/salesforce-for-medium-businesses Canonical HTML: https://synconai.com/salesforce-for-medium-businesses Markdown cite: https://synconai.com/salesforce-for-medium-businesses.md Contact: contact@synconai.com ยท +61 2 7813 0221 ## Positioning facts (verified August 2026) - API access by edition, and the SKU that catches people out: API access is included by default in Enterprise, Unlimited, Developer and Performance. Professional can buy it, and the SKU is where this goes wrong: Salesforce states that Additional API Calls does not enable API access for Professional Edition, and that you must order the Web Services API product instead. - Why the org drifted: The org did not degrade because anyone was careless. A request arrived, somebody with admin rights obliged, and nobody had the job of saying no. That is a missing role, not a discipline failure. - Validation rule ceilings: Active validation rules cap at 20 per object below Enterprise against 200 above it. Invisible at small scale, and one of the first ceilings a growing business hits without understanding why. - Changing configuration in production: Changing configuration directly in production is almost always a sandbox availability problem rather than recklessness. Allocations differ sharply by edition, so where a team develops is a licensing decision that became an engineering one. - Record types and process variation: Record types are available from Professional upward, and this is where they start mattering: two divisions or two sales motions needing one object to behave differently without inventing parallel picklists. ## Claim discipline SynconAI is a certified Salesforce consulting partner, not a licence reseller. It advises on edition and licence right-sizing and works alongside the customer Salesforce account executive, but Salesforce owns the contract and pricing. Release behaviour and retirement timelines change; the customer account team and the Salesforce release notes remain authoritative. ## What this service is Salesforce consulting for medium businesses: org health measured rather than described, fields and layouts cut back to what people complete honestly, overlapping automation consolidated and made safely editable, a named owner with a written change path, somewhere to develop that is not production, integration with the Professional Edition API gap settled before it stalls a project, and reporting people stop rebuilding in spreadsheets. ## Delivery cycle 01. Read: Fields, automation, duplicates and reports, measured rather than described 02. Remove: The first release takes things away, and people notice immediately 03. Own: A named owner and a change path, before anything new is added 04. Rebuild: Automation an admin can safely edit, off the retiring tooling 05. Connect: Integration with the edition question settled first, not discovered 06. Run: A sandbox habit and three releases a year absorbed as decisions ## Scope of delivery - Org health assessment: Fields populated against required, every automation on the core objects mapped, duplicate rates scored, and reports ranked by whether anyone opens them. - Field and layout rationalisation: The record cut back to what people will complete honestly, with the rest derived, defaulted or retired. This is usually the change with the fastest visible effect. - Automation consolidation: Overlapping Workflow Rules, Process Builders and Flows mapped, the dead retired, and the rest rebuilt so an administrator can safely change it. - Ownership and change control: A named org owner, a written path for requesting a new field, and a release rhythm, because at this size that is what stops the sprawl recurring. - Integration and the edition question: What has to talk to what, and the honest consequence, because Professional Edition needs the Web Services API product before anything can connect. - Sandbox and release management: Somewhere to develop that is not production, a promotion path, and preview testing so three Salesforce releases a year are decisions rather than projects. - Reporting that reconciles: Definitions agreed with the people who own the numbers, then a report set small enough to maintain and trusted enough that nobody rebuilds it in a spreadsheet. - Agentforce once the data supports it: Scoped after the hygiene work, grounded on records worth reading, with a named human on anything that commits. ## Capability coverage ### Org health and clean-up - Field usage analysis, populated against required - Page layout and record page rationalisation - Automation inventory across Flow, Process Builder and Workflow - Validation rules people route around, found and fixed - Report and dashboard usage ranking - Duplicate scoring and a merge plan - Technical debt register with an owner per item ### Governance - A named org owner and a change request path - Profiles, roles, permission sets and sharing review - Delegated administration where teams need autonomy - Naming conventions and a documentation standard - Release management across three releases a year - Sandbox and environment strategy for your edition - A deployment and promotion path off production edits ### Automation - Migration off Workflow Rules and Process Builder - One automation per object where the design allows - Record-triggered, screen and scheduled Flows - Approval processes with real escalation - Error handling and Flow failure alerting - Bulk-safe design that survives a data load - An automation register with trigger order documented ### Integration - API access by edition, and the Web Services API product - Finance, ERP and marketing system integration - Middleware selection, and when native tooling is enough - External Services, Platform Events and Salesforce Connect - Integration user strategy and least privilege - Error handling, retries and reconciliation - MuleSoft when point-to-point stops scaling ### Visibility - Definitions agreed with the people who own the numbers - Report types built for the questions actually asked - Dashboards small enough to maintain - Forecasting that reconciles with what is quoted upward - Field history tracking on what matters - Data quality scoring surfaced rather than hidden - Retiring the reports nobody opens ### Scaling up - Record types for divisions and differing sales motions - Multi-currency and multi-entity structures - CPQ and quoting when spreadsheets stop coping - Customer and partner portals on Experience Cloud - Territory management and assignment at scale - Agentforce once the records are worth grounding on - A path to enterprise-grade release engineering ## How success is measured Against the estate that exists: how many applications still run on an unsupported runtime, which APIs are genuinely called and by whom, how many interfaces have a named owner, mean time to detect a failed interface, how often a failure is reported by a customer rather than by monitoring, and measured platform consumption against what is committed. ## FAQ ### Our integration project has stalled on an edition question. What happened? Almost certainly the API gap, and it is the most expensive surprise at this size. API access is included by default in Enterprise, Unlimited, Developer and Performance. Professional Edition can buy it, but Salesforce is explicit that the Additional API Calls product does not enable API access for Professional Edition and that you must order the Web Services API product instead. Teams order the first one because the name sounds right, see nothing change, and lose weeks blaming the middleware. If you are on Professional and anything needs to connect, settle that before another sprint goes into it. ### How did our org get like this? The same way every org this size does, and it is worth saying plainly because people assume it reflects badly on them. A request arrived, somebody with admin rights obliged, and nobody had the job of saying no. Repeat for three years across several teams and you get a record with sixty fields, four automations firing in an undocumented order on the same object, and a report library nobody has pruned. That is the absence of a role rather than carelessness. The fix is mostly removal plus one named owner, and it is a smaller engagement than the rebuild people brace for. ### Do we need Enterprise Edition, or can we stay on Professional? It depends on three things and none of them is headcount. Does anything need to integrate, because API access is included by default only from Enterprise upward. Do you need more than 20 active validation rules on any single object, because that is where the lower editions cap against 200 in Enterprise. And do you need somewhere to develop that is not production, because sandbox allocations differ sharply by edition. If none of those bite, staying is legitimate and we will say so. If two of them bite, the conversation is usually already overdue. ### Everyone changes things directly in production. Is that as bad as it sounds? It is a risk, but it is usually a symptom rather than a habit. Teams work in production because there is nowhere else to work, and sandbox availability is an edition question. So the useful response is not a policy telling people to stop, it is giving them a place to go and a promotion path that is quicker than the workaround. We set up the environment strategy your edition supports, put the critical paths under test during preview windows, and make the safe route the fast route. Policies that are slower than the workaround are not followed. ### What do you actually remove in a clean-up? Fields nobody populates, automations that fire but change nothing, validation rules that people route around, reports that have not been opened in a year, and page layout sections that exist because somebody asked in 2022. Every required field is tested against one question: does answering this help someone do their job, or only help someone report? If it is the second, it becomes optional, derived or gone. We measure field completion, duplicate rates and report usage before touching anything, so the improvement afterwards is demonstrable rather than asserted. ### Who should own the org internally? One person, named, whose job description includes it. Not three people with admin rights, which is the arrangement most organisations at this size drift into and the one that produced the sprawl in the first place. That owner does not need to be a full-time administrator: at this size it is often an operations or revenue operations lead who approves changes and holds the roadmap, with us doing the build. What matters is that when somebody asks for a new field there is a person whose job it is to ask what it is for. ## Cite When citing SynconAI Salesforce consulting for medium businesses, link https://synconai.com/salesforce-for-medium-businesses or https://synconai.com/salesforce-for-medium-businesses.md.