Your journey for superior customer and business experience

How to choose a Salesforce implementation partner: a buyer-side checklist

Tekunda Team — Wed, 11 Nov 2026 14:25:46 GMT

Short answer: choose on evidence of delivery, not on the rate card. Ask for three things you can verify: a reference project in your industry with a named outcome, the certifications of the specific people who will sit on your team rather than the firm's total, and a written description of what support looks like the week after go-live. A cheap day rate that produces rework is the most expensive option on the table.

Why does the rate card mislead so reliably?

Because it prices a seat, and you are buying an outcome. Three patterns repeat:

The blended rate hides the bench. One average number can mean a senior architect for a week and juniors for six months. Ask for the team composition per phase.
Rework is invisible at signing. Configuration that ignores your data model looks identical on a status report to configuration that fits it. The difference surfaces in month five, as change orders.
The scope cut to hit the number was the integration. Salesforce projects rarely fail at the CRM. They fail at the boundary: the ERP, the telephony, the identity provider, the migration nobody costed.

None of that argues for the highest bid. It argues for comparing the total cost of a working system, and asking each bidder to show where their number will move.

Do Salesforce partner tiers still tell you anything?

Less than they did, and the rules have just changed. On 3 March 2026 Salesforce overhauled its consulting partner program: the four tiers of Base, Ridge, Crest and Summit collapse into two, Select and Summit, and 170 Navigator badges become 28 competencies, each recognised at Accredited or Expert level.

The useful part for a buyer is how a competency is earned: certifications, completed projects and customer satisfaction scores. That makes it a claim about delivery history rather than about sales volume. Two consequences:

A tier badge quoted in an older deck or case study may no longer mean what it meant. Ask what the partner holds today.
A competency in the exact product you are buying, whether that is Agentforce, Data Cloud or Field Service, is worth more to you than a higher overall tier earned somewhere else.

What delivery proof should you ask for?

Ask for artifacts, not adjectives. A partner who has done the work can produce these within a day:

One reference project in your industry, with the before-and-after number attached and a client willing to take the call.
A redacted solution design from a past project. You are checking whether they document decisions or improvise them.
Their deployment method. How does a change get from a developer to production, who approves it, and how is a bad release rolled back? If the answer is change sets and a spreadsheet, you will feel it every release.
A named failure. What went wrong on a recent project, and what changed afterwards? A partner with no answer has either no history or no candour.

Which certifications actually matter?

The ones held by the people who will be on your project. A company-wide certification count is a recruitment statistic. What matters is:

An architect credential on whoever owns the data model, if you have more than one source of customer truth.
A product certification matching your real scope: Field Service, Service Cloud, Data Cloud, CPQ. Generalists make you pay for discovery twice.
PDO or ISV experience if anything you build will be packaged, distributed or taken through AppExchange security review. That is a different discipline from org configuration, and the one most often assumed.

Salesforce certifications are individually verifiable, so verify them. Name the delivery team in the statement of work and make substitutions require your approval.

Who will actually do the work?

The pitch team is rarely the delivery team. Three questions settle it: who is full time on your project rather than allocated across four, in which time zones, and whether any of the work is subcontracted. None of these has a wrong answer. A partner who will not answer them plainly has given you one anyway.

What does support look like after go-live?

Get it in writing before you sign, in these terms:

The hypercare window, how long it lasts and who is in it.
Response targets by severity, and what qualifies as severity one.
Who holds the knowledge if your admin leaves, and where the documentation lives.
How enhancements are funded once the project budget closes.

Salesforce ships three releases a year, so "done" is not a state your org gets to occupy. The partner who plans for that costs less over three years than the one who books the launch party.

What are the red flags?

A fixed price quoted before any discovery. It is either padded or it will be reopened.
No questions about your data. Migration is where schedules die.
Certifications quoted as a company total.
Reluctance to name the delivery team.
Custom code proposed where configuration would do, or the reverse, with no stated reason.

Tekunda is a certified Salesforce SI, ISV and PDO with 20+ organisations live in production, and we would rather publish the numbers than the adjectives: for ASSA ABLOY, weekly cases fell from 3,000 to 350 across 11,000 connected devices, with no added support staff. Ask us for exactly the proof you should ask anyone else for. See what we build.

FAQ

Is a bigger Salesforce partner safer?

Not inherently. Scale buys coverage and continuity, a smaller firm usually buys seniority on your actual project. Decide which risk matters more for your scope.

How long should choosing a partner take?

Two to four weeks for a shortlist of three, reference calls included. Beyond that the business case ages faster than the evaluation improves.

Should I run a paid discovery before the full project?

Usually yes. A short paid discovery buys you a real estimate and a sample of how the partner works, for a fraction of the cost of finding out mid-build.

What if the partner I like lacks one skill I need?

That is normal, and fine if they say so upfront. Ask how the gap is covered, by whom, and who is accountable where the two halves meet.

Salesforce Release Management for Small Admin Teams

Tekunda Team — Sun, 08 Nov 2026 12:00:00 GMT

TL;DR: Salesforce release management for a small admin team comes down to four habits: a shared release calendar, every change tracked in one place, a test pass in a sandbox before production, and a written rollback plan. You do not need a dedicated DevOps engineer to run it. Start with DevOps Center or change sets, and add the Salesforce CLI once the volume of change outgrows clicks.

What is Salesforce release management for a small admin team?

It is the process that decides which changes reach production, when they go, and how you prove they work. For a team of one to five admins it is less about tooling and more about one rule: nobody deploys something the rest of the team cannot see.

Small teams carry a load that large teams split across roles. The same person gathers the requirement, builds the Flow, tests it, deploys it and answers the support ticket when it breaks. A light process protects that person from overwriting a colleague's work or shipping into the middle of a Salesforce upgrade.

Why should a small team plan releases around Salesforce's own releases?

Salesforce ships three major releases a year: Spring, Summer and Winter. Spring '27 arrives in January 2027, and some security release updates are enforced before the release window opens, starting with the OAuth 2.0 Device Flow restriction on November 30, 2026.

This is the part most release guides skip. A small team's calendar has two layers: your changes and Salesforce's. Preview sandboxes upgrade weeks before production, and Lightning Record Pages and Flows change structure between releases, so a deployment from a preview sandbox to a production org still on the old release is where things quietly break. In practice:

Know which of your sandboxes sit on the preview instance before the upgrade starts.
Hold Flow and Lightning page deployments while sandboxes and production run different releases.
Test each release update in a sandbox first, then enable it in production on a date you chose, not the date Salesforce enforces it.

What does a lightweight release process look like?

Log every change as a work item. One request, one owner, one record of what changed and why.
Build in a sandbox, never in production. Even a quick picklist value goes through the same path.
Keep metadata in source control. A single branch is enough to start. It is the foundation of the metadata governance you will need as the org grows.
Test with a real user. Ask one person from the affected team to run their daily task in the sandbox.
Tell users before you deploy. A two-line message saying what changes and when prevents most surprise tickets.
Deploy outside working hours with a rollback plan. Write down what you would reverse and how, before you click deploy.
Smoke-test and write release notes. Check the three screens people use most, then record what shipped.

Change sets, DevOps Center or the Salesforce CLI: which should you use?

Change sets: built into Setup with no tooling to install. They are built by hand, have no version control and no native rollback, and must be recreated for each new target org.
DevOps Center: point-and-click change tracking backed by Git. The next generation of DevOps Center runs natively in your production org with no managed package, works with GitHub and Bitbucket, and adds a dependency viewer, a Tests tab and DORA metrics.
Salesforce CLI: scripted, repeatable deployments for teams ready to automate. Our guide on how the Salesforce CLI turns admin work into repeatable code shows the first commands worth learning.

Rule of thumb: if two admins have ever overwritten each other's change, move off change sets. If you deploy more than once a week, start scripting.

What is a headless MCP server, and does it matter for release management?

A headless MCP server exposes a platform's capabilities as tools that AI agents call through the Model Context Protocol, with no user interface in between. Salesforce launched Headless 360 at TDX in April 2026 to make the platform reachable through APIs, MCP and the CLI, and the Headless 360 MCP Server entered beta in July 2026. It runs under the calling user's permissions, including object, field and sharing access. The new DevOps Center also exposes its operations through the Salesforce MCP.

For a small team this is extra capacity, not a replacement. An agent can draft release notes, check metadata dependencies or prepare a work item, while an admin still approves the promotion. Tekunda is the first and only partner running headless CRM plus MCP in production, and the first to run agent-to-agent (A2A) and SWARM orchestration in production. We use both to add hands to admin teams on top of their Salesforce investment.

When should a small admin team bring in a partner?

When releases start colliding, when one admin holds all the knowledge, or when the org carries specialised data such as devices and assets. Connected-device programs are a good example: the triage rules behind how connected-device teams cut support cases by 93 percent stay reliable because they are versioned in source control, deployed through a pipeline and can be rolled back. Tekunda is a certified Salesforce SI, ISV, PDO and Agentforce partner, and an Anthropic (Claude) partner. If your release process needs a second pair of hands, talk to our team.

FAQ

Do small Salesforce teams really need release management?

Yes. A light process with a calendar, tracked changes and a rollback plan prevents most production incidents, and it takes hours to set up, not weeks.

Is DevOps Center free?

DevOps Center is included at no extra cost with Professional, Enterprise, Performance, Developer and Unlimited editions. Professional edition needs API access.

Should I deploy during the Salesforce sandbox preview?

Avoid deploying Flows and Lightning pages from a preview sandbox to a production org that has not upgraded yet. Wait until both run the same release.

Can AI agents run Salesforce releases?

Agents can prepare work through MCP, such as release notes and dependency checks, under the user's own permissions. Keep a human approval on every production promotion.

Agentforce vs Custom AI Agents: When to Configure and When to Build

Tekunda Team — Sun, 08 Nov 2026 06:01:04 GMT

Short answer: configure Agentforce when the job is a bounded set of actions on data Salesforce already holds. Build your own AI agent when the hard part is the reasoning rather than the action, or when the decisive data lives outside the CRM. Most serious deployments in 2026 end up doing both, with a deliberate seam between them.

What is the actual difference?

Agentforce is Salesforce's agent layer. It runs on the Atlas Reasoning Engine, is configured in Agentforce Builder rather than coded from scratch, and inherits the platform's identity, sharing model, audit trail and governor limits (Agentforce Developer Guide).
A custom AI agent is software you own: your model choice, your retrieval, your tools, your orchestration, running wherever you want, against whatever systems you have.

The trade is not "easy versus powerful". It is bounded and governed against unbounded and yours. Both are the right answer roughly half the time.

What changed in Agentforce since 2025?

The line between configuring and building has moved, so an older comparison will mislead you. Four changes matter for this decision:

Hybrid reasoning with Agent Script. Agentforce 360, generally available since October 2025, lets developers define guardrails, tool use and logic in Agent Script, combining deterministic workflows with LLM reasoning (Salesforce). Salesforce says Agent Script is included with Agentforce at no extra cost (Salesforce).
More model choice. Customers can run Anthropic models via Amazon Bedrock, Google Gemini and OpenAI models inside Agentforce, so "you need model choice" is a weaker reason to build than it was.
Open doors to outside agents. Agentforce 3 announced a native MCP client so agents can connect to MCP-compliant servers (Salesforce). In August 2026 Salesforce put a Headless 360 MCP Server into open beta, letting agents discover and act on Salesforce capabilities at runtime (CX Today).
Prebuilt agents and orchestration. In September 2026 Salesforce released a portfolio of job-ready agents for service, IT and HR, commerce and supply chain, with Multi-Agent Orchestration generally available (Salesforce).

The net effect: configuring now covers more ground, and building no longer means working outside Salesforce. The decision is about where the reasoning lives, not which vendor you pick.

Agentforce vs building your own AI agent, side by side

Time to first agent: Agentforce is faster when the work is CRM-shaped. A custom agent is faster only when the CRM is a minor data source.
Security and sharing: Agentforce inherits them. A custom agent must rebuild them or route its writes back through the platform.
Reasoning control: Agentforce gives you topics, actions and Agent Script. A custom agent gives you the whole loop, including planning and evaluation.
Data reach: Agentforce is strongest on Salesforce and Data 360. A custom agent treats every system as equal.
Pricing model: Agentforce Flex Credits cost $0.10 per action, or there are per-user licenses (Salesforce). A custom agent costs model tokens, hosting and the engineers who keep it running.
Who maintains it: admins and Salesforce developers for Agentforce; an engineering team for a custom agent.

When should you configure Agentforce?

Configure when most of these are true:

The data that decides the answer is already in Salesforce, or is landing in Data 360.
The work is CRM-shaped: case deflection and routing, service replies, opportunity hygiene, scheduling, guided sales actions.
The actions are enumerable. You can list what the agent is allowed to do, and the list is short enough to write on a whiteboard.
Governance is the hard requirement. Permissions, sharing and audit come free because the agent is inside the platform.
You have admin capacity. Someone fluent in Flow, permission sets and the data model will get further, faster, than a team of engineers starting cold.

The compounding reason people miss: an agent inside the platform inherits the platform's security model. Rebuilding that in a custom stack is expensive and easy to get subtly wrong. If this is your case, our Agentforce implementation work starts from exactly this list.

When should you build your own AI agent?

Build when any one of these is true, because each is individually disqualifying for a configure-only approach:

The decisive data is not in the CRM. Telemetry, ERP, documents, ticketing, a warehouse, a device fleet. If the agent needs to reason over all of it, the CRM is one source among many.
The reasoning is the product. Multi-step analysis, planning, ranked recommendations with justification, or anything where the answer needs defending rather than executing.
The workflow is not a CRM workflow. Operations, engineering, supply chain, field diagnostics.
You need control over the whole loop. Your own evaluation, your own retrieval, model routing per task, and release cadence you decide.
The agent must run where the users are, and the users are not in Salesforce.

Building is also where most projects go wrong, usually on evaluation and error handling rather than the model. We wrote up why most AI agents fail in production and what we changed to ship one that holds up.

What is the one test that settles most cases?

Write the agent's job as a list of actions. If you can, and every action reads or writes something Salesforce already knows, configure. If the hard part is deciding which action, on evidence from several systems, build.

That test is faster than a bake-off and it is honest about the failure modes. Configure-only projects fail when a bounded action list turns out to need unbounded judgement. Build-only projects fail when a team spends a quarter reimplementing sharing rules, audit trails and case management that were already there.

Why is the answer usually both?

Because the two layers want different jobs. Agentforce is a good surface: it sits where service and sales people already work, with the platform's governance around it. A custom agent is a good brain for anything that has to reason across systems. Connect them, and each does what it is good at.

That seam is now a first-class platform concern rather than a hack. Salesforce ships Model Context Protocol interfaces in its own tooling, including a Salesforce DX MCP Server behind the next generation of DevOps Center (Salesforce Help). MuleSoft Agent Fabric, announced in April 2026, adds a control plane that discovers and governs agents across vendors, including Amazon Bedrock and Microsoft Foundry (Salesforce). Agent-to-agent handoffs and MCP action hubs are how a governed CRM agent calls specialist agents without either side swallowing the other.

This is the architecture we build most often at Tekunda. We are a certified Salesforce SI, ISV and PDO and an Anthropic partner, we were first to put Agentforce agent-to-agent orchestration and SWARM architecture into production, and we build headless CRM and MCP action hubs so agents can act across systems from one place. On the connected-device side, our work for ASSA ABLOY cut weekly cases from 3,000 to 350, a 93% reduction across 11,000 devices and up to 2.5 million events per week, in three markets with no added support staff. See how we design custom AI agents that plug into Salesforce.

How do you decide without a six-month bake-off?

Write the action list. Ten minutes, on a whiteboard, with the people who do the job today.
Mark the data source next to each action. Count how many sit outside Salesforce.
Ask what breaks if the agent is wrong. High blast radius pushes toward the governed platform layer.
Put a number on the value. Price the Agentforce path in actions and the custom path in tokens and engineering time, then compare both against the before-number. Our guide to driving ROI from AI agents covers which numbers to track.
Pilot the smaller half first. Whichever side is bounded, ship that, and let the seam wait until the value is proven.

If you want a second opinion on your action list, talk to our team.

FAQ

Is Agentforce enough on its own?

For CRM-bounded work on Salesforce data, usually yes. It stops being enough when the decisive evidence lives in systems Salesforce does not own.

Can a custom AI agent work with Agentforce rather than replace it?

Yes, and that is the common pattern. Agentforce holds the governed CRM surface, custom agents handle cross-system reasoning, and they hand off to each other over MCP or agent-to-agent calls.

Does building custom mean giving up Salesforce governance?

Only if you architect it that way. Keep CRM writes going through platform actions and you keep the sharing model and audit trail intact.

Is Agentforce cheaper than building your own AI agent?

Not reliably. Agentforce bills per action or per user, a custom agent bills in tokens and engineering time, and the totals converge more often than people expect.

Where should a first project start?

With one workflow that has a clear owner and a measurable before-number. Agent projects that begin as platform strategy tend not to finish.

Signs Your Salesforce Org Needs a Health Check

Tekunda Team — Sat, 07 Nov 2026 12:00:00 GMT

TL;DR: Your Salesforce org needs a health check when people stop trusting its reports, automation fires in ways nobody can explain, permissions have sprawled beyond what anyone can audit, or releases keep breaking things. In 2026 there is a new trigger as well: AI agents can now reach your org through APIs and MCP, so every weak setting your team once tolerated becomes something an agent can act on.

What is a Salesforce org health check?

A health check is a structured review of how your org is built and used: security settings, data model, automation, code, integrations and adoption. It ends in a ranked list of fixes, not a rebuild. It is lighter than a formal audit, which tests the org against a compliance standard. If an audit is what you actually face, start with our guide on how to prepare your Salesforce org for an audit.

What are the signs your Salesforce org needs a health check?

Nobody trusts the reports. Teams export to spreadsheets to re-check the numbers, or two dashboards disagree about the same pipeline.
Duplicates keep coming back. Clean-up projects fix the symptom and the duplicates return within a quarter, which points at intake rules and integrations, not at users.
Automation nobody remembers building. Flows, triggers and legacy workflow rules overlap on the same object and fire in an order nobody can explain.
Permissions have sprawled. Users hold powerful permissions granted for a one-off task, profiles have been cloned and patched for years, and no one can say who can export what.
Releases break things. Every deployment causes a regression, or the team avoids deploying at all.
Integrations fail silently. Data from ERP, billing or field systems arrives late or not at all, and someone finds out from a customer. Our article on Salesforce and SAP integration patterns for manufacturers covers designs that avoid this.
The people who built it have left. When the admin or partner who knew the org moves on, the undocumented decisions leave with them.
The business changed and the org did not. A merger, a new product line or a new team inheriting the org leaves configuration designed for a company that no longer exists.

One sign is a nuisance. Three or more usually share a root cause, and finding that root cause is where a health check pays for itself.

What is headless MCP, and why does it raise the stakes?

Salesforce is opening its platform to agents. At TDX on April 15, 2026 it launched Headless 360, which exposes data, workflows and governance controls as APIs, MCP tools and CLI commands, and Salesforce Hosted MCP Servers reached general availability the same month. Headless MCP simply means an agent works with your CRM through the Model Context Protocol instead of the browser.

That changes what an unhealthy org costs. A person stumbles over a loose permission set; an agent uses it at machine speed. Duplicate records confuse a rep; they lead an agent to a wrong answer delivered with full confidence. Tekunda was the first to run agent-to-agent (A2A) and SWARM orchestration in production, and is the first and only partner in headless CRM plus MCP, so we treat every health check as an agent-readiness check too. For the access side, read how to keep a Salesforce org secure as your team scales.

Can a health check help calculate the ROI of Agentforce?

Yes, because it supplies the inputs calculators leave out. Salesforce's own Agentforce ROI calculator estimates three-year benefits and the Flex Credits a use case may need, but it states that Salesforce licences, Data 360 credit costs and implementation costs are not included, and that results are illustrative only. A health check measures how much data clean-up, permission work and automation consolidation stand between you and a working agent. That is the implementation figure the calculator expects you to bring yourself.

Data 360, the platform formerly called Data Cloud, was renamed at Dreamforce 2025 as the data foundation for Agentforce, so its readiness belongs in the same review.

What can you check yourself first?

Salesforce Health Check. In Setup, search Quick Find for Health Check. It scores your security settings from 0 to 100 against the Salesforce baseline, called Standard Values, and regulated teams can import a custom baseline. Salesforce warns that the Fix Risks button changes every flagged setting at once and can break integrations or remove access, so test in a sandbox and change settings one at a time.
Org Check. Salesforce Optimizer has been retired: access was removed in the Winter '26 upgrade for Hyperforce orgs and in Spring '26 for the rest. The free Org Check app from Salesforce Labs covers metadata quality, security and automation, but it is not an official Salesforce product and has no Salesforce Support.

Both tools tell you what is misconfigured. Neither tells you why the org drifted, which fixes matter most to the business, or what has to change before agents arrive. That judgement is the health check.

What should a health check deliver?

A ranked findings list tied to business impact, not a raw export.
An access map showing who can see, edit and export which data.
An automation inventory per object, with overlaps flagged.
A data quality baseline you can re-measure next quarter.
A roadmap that separates quick wins from structural work.

If you sell on AppExchange, add security review readiness to the scope; a Salesforce PDO can run that alongside the org review. Tekunda is a certified Salesforce SI, ISV, PDO and Agentforce partner, and the goal is always to get more from the Salesforce you already run, never to cut it back. See how we engage to scope a health check for your org.

FAQ

How often should a Salesforce org get a health check?

At least once a year is a common rule of thumb. Run one again after a merger, a major platform change or a new team taking over the org.

Is Salesforce Health Check the same as an org health check?

No. Salesforce Health Check scores security settings only. An org health check also covers data, automation, code, integrations and adoption.

Is Salesforce Optimizer still available?

No. It was retired across Winter '26 and Spring '26, and Salesforce Labs' free Org Check app is the usual replacement.

Does a health check mean cutting Salesforce licences?

No. The aim is to get more value from the platform you already pay for and to prepare it for what comes next, including Agentforce.

Headless MCP on Salesforce: How to Adopt Headless 360 and Size the ROI

Tekunda Team — Sat, 07 Nov 2026 06:04:34 GMT

The Headless 360 MCP Server is Salesforce's hosted Model Context Protocol endpoint that gives any MCP client four tools - discover, describe, dispatch and dispatch read only - over a growing library of platform skills, with no user interface in the loop. It has been in open beta since July 2026 and sits on top of Salesforce's standard hosted MCP servers, generally available since April 2026. The agent authenticates as a real user and runs CRM and setup work under your org's existing security, so a natural-language prompt becomes a governed Salesforce operation. This guide covers what headless MCP is, how the server works, how to turn it on, what it can do today, the security it enforces, the agent metering Salesforce has announced, how to adopt it safely, how to size the ROI, and where a partner fits. We run headless MCP in production at Tekunda, so the adoption rules below are the ones we apply on every rollout.

What is headless MCP on Salesforce?

The Model Context Protocol is an open standard that lets an AI model discover and call external tools, APIs and data at runtime, so any compatible client can talk to any compatible server without custom glue code. "Headless" means there is no screen in the loop: the work runs through the API and agent layer instead of clicks in the Lightning UI. Together, a headless MCP setup lets Claude, ChatGPT, Cursor, Agentforce or any MCP-compatible client read records, run queries and execute setup operations by calling Salesforce tools directly. The person sets the intent; the agent finds the right operation and executes it.

That matters because most agentic prototypes never reach production. They work in a demo, then fall over the moment they meet real permissions, real data volumes and a security team. Headless MCP closes that gap because the agent inherits context and policy from the platform rather than reinventing them.

What is Salesforce Headless 360?

Salesforce introduced Headless 360 at TDX in April 2026 as an initiative to expose every platform capability as an API, an MCP tool or a CLI command, so the browser becomes optional rather than required. Per the Salesforce Developers blog, it launched with 60+ MCP tools, 30+ coding skills, more than 4,000 existing APIs and 220+ CLI commands. Salesforce's product page now markets that layer as the Headless Toolkit, while the server and its documentation keep the Headless 360 name, so expect to see both.

Separate the layers, because several of them carry the Headless 360 name:

The standard hosted MCP servers handle record work: SObject All, Reads, Mutations and Deletes, plus Tableau Next. Generally available since April 2026 for Enterprise Edition and above.
The Headless 360 MCP Server collapses setup and integration work into four tools across the whole platform. In open beta since July 2026.
The Data 360 MCP Server works only with Data 360 data and is generally available, per Salesforce's August 2026 expansion.

How does the Headless 360 MCP Server work?

Its headline idea is restraint: agents get four tools, not four thousand. An org has thousands of features, and loading every endpoint into a model's context wrecks its decision-making, so the server presents a small, stable surface and does the routing itself:

discover - semantic search across a vector index of APIs and skills, returning ranked candidates for the request.
describe - the technical spec for a chosen skill: parameters, dependencies, ordered steps.
dispatch - invokes a skill, with access control enforced.
dispatch_readonly - a separate path that runs read-only operations.

The discover-describe-dispatch loop keeps the model's context small while the catalogue behind it grows. The beta launched with roughly 100 skills, most of them admin Setup tasks, with thousands planned.

How do you turn on the Headless 360 MCP Server?

No code is needed for a first connection. The hosted servers follow one pattern, which the Apex Hours hands-on walkthrough documents end to end:

Activate the server. In Setup, open the Salesforce Hosted MCP Servers list, find Headless 360 (or a narrower server such as SObject Reads) and click Activate. Every server ships disabled.
Create an External Client App. Enable OAuth, add your client's callback URL, and grant only the mcp_api and refresh_token scopes. Require PKCE and JWT-based access tokens for named users.
Connect the client. In Claude, for example, add a custom connector with the server's remote MCP URL and the app's consumer key and secret, then sign in through Salesforce.
Set permission modes per tool. Start every write tool on "needs approval" rather than "always allow".

Allow up to 30 minutes for a new External Client App to propagate before you debug an OAuth error, and use the sandbox endpoint for your first sessions.

What can headless MCP do in Salesforce today?

At launch the Headless 360 MCP Server covers:

User management, including creating and deactivating users, resetting passwords and assigning permissions.
Apex trigger development.
Event-driven integrations across Change Data Capture, platform events and event relays.
Named credential configuration.

Beyond setup, the hosted record servers let an agent list leads, run SOQL and update fields in natural language, and Data 360's MCP surface exposes more than 200 APIs so an agent can build, map and query unified data with plain-language requests. The same pattern extends to the systems around Salesforce: a telephony integration that syncs call logs to records, or a WhatsApp conversation, becomes another set of governed actions an agent triggers, with Salesforce still the system of record. Instead of a custom connector for every AI surface, you expose one governed server and any MCP-aware client reaches it.

The ecosystem around it moved fast after launch:

19 August 2026: Salesforce made the Slackbot MCP Server and Client, the Data 360 MCP Server and a repository of 100+ agent skills generally available, while the Headless 360 MCP Server stayed in open beta.
26 August 2026: Salesforce and Anthropic announced Claudeforce, starting with a Salesforce in Claude plugin of 37 prebuilt sales skills for pilot customers.
14 September 2026: Copado extended Agentia with Headless, using MCP and command-line interfaces, with availability from November 2026.
2 November 2026: the local Salesforce DX MCP server reached end of life, with developer tooling moving to skills. The hosted servers are unaffected.

Budget for beta, not GA, while you evaluate: the Headless 360 MCP Server itself is still in open beta as of this update, and Salesforce notes that server URLs and OAuth scopes can change between beta and GA.

Is headless MCP secure?

An agent that can create users and deploy Apex is exactly as dangerous as the permissions behind it, so this is the question that matters. The reassuring part is that Headless 360 does not invent a new trust model; it rides on the one Salesforce already enforces. Every transaction runs as an authenticated user, scoped through an External Client App with the mcp_api scope and OAuth 2.0 with PKCE, and every action is bounded by four layers:

Identity - the agent acts as an authenticated user, never above them.
Access - profiles, permission sets, org-wide defaults, sharing rules and field-level security still apply.
Invocation scope - only explicitly exposed skills can be called.
Governance - validation rules, transaction security policies, approval chains and governor limits still fire.

If a person cannot do it in Salesforce, their agent cannot do it through MCP either. Salesforce also ships the standard servers disabled and separates read, create/update and delete into different servers, so you never grant delete by accident. Enable it deliberately, because "delete all leads" is one prompt away once you do.

The identity model is about to get stricter. Salesforce has announced Agentic Identity, under which agents are registered on the platform with their own credentials and permissions instead of borrowing a user's, and MCP clients will eventually move to OAuth credentials tied to that registered identity. Design your permission sets now as if each agent were already its own user, and the migration becomes a configuration change.

How do you adopt headless MCP safely in production?

The demos are easy. Production is where teams get burned. The rules we apply at Tekunda on every rollout:

Start read-only. Give agents dispatch_readonly or the SObject Reads server before any write path is live.
Scope a dedicated permission set. The agent inherits its user's access, so give it its own least-privilege user, not an admin login.
Require approval for writes. Keep the client's permission mode on "needs approval" for create, update and delete until you trust the flow. Once a tool is approved in a session, later calls may run without a fresh prompt.
Log every dispatch. Capture which skill ran, as whom, and against what records, so an agent action is as auditable as a human one.
Rehearse in a sandbox. Never let a new skill touch production data on its first run.
Plan for agent registration. Inventory every MCP client and API agent that touches the org, so registering them under Agentic Identity is a checklist, not an investigation.

The security Salesforce enforces is a floor, not a strategy. The risk is not the protocol; it is over-broad permissions on the connected user, and an agent acting as that user can still do broad damage fast. If you are wiring several agents together, or want one action surface that spans Salesforce and the ERP, telephony and devices around it, the handoff design matters as much as the permissions - see running CRM actions from one agentic hub and what makes agent-to-agent handoffs work in production. When you want that rollout designed and governed properly, our headless MCP team does exactly this work.

What belongs on a security review checklist for MCP-connected apps?

If you package software for the AppExchange, exposing capabilities over MCP does not exempt you from the AppExchange Security Review; it raises the stakes. Our short version, drawn from shipping through the review ourselves:

Enforce CRUD, FLS and sharing in every Apex entry point an agent can reach, not just the UI.
Kill SOQL injection with bind variables, never string-built dynamic SOQL.
Encrypt data in transit with TLS 1.2 or higher and at rest with AES-256.
Scope named credentials and connected apps to the minimum, and prove it.
Set security headers and cookie flags (X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security, Secure and HttpOnly).
Scan before you submit with Salesforce Code Analyzer plus a scanner such as Checkmarx, OWASP ZAP or Burp Suite, and document every false positive.
Document data storage, authentication and every external integration the agent uses.

Agentic surfaces add one line to that list: confirm no tool can escalate beyond the running user's permissions. A headless surface removes the human who used to be the last check, so the org's own controls have to carry that weight. Treat the agent as another authenticated client: if each dispatch would pass review on its own, the headless layer above it will too.

For those controls in the order that matters, work through our Salesforce security review checklist, and when the scanners flag issues you have already handled, our guide to documenting false positives keeps them from stalling your submission.

How do you size the ROI of a headless MCP rollout?

Size it before you build. Salesforce publishes an Agentforce ROI calculator that projects cost savings and efficiency over a three-year horizon and estimates the Flex Credits a use case will consume. It is a fair starting point, but it runs on generic assumptions, and a defensible model uses your numbers. Our Agentforce ROI tool lets you plug in your own volumes, handle times and rates.

Ground it with a simple frame, all normalized to a monthly figure: (hours saved per process x monthly volume x loaded rate) - (monthly Flex Credit spend + build cost divided over the payback horizon + monthly governance). Convert Flex Credits to their currency cost so every term is money per month. Headless MCP moves the "hours saved" side hardest on repetitive, multi-step setup and data tasks, the work that used to mean a dozen clicks across several screens, because it removes the interface tax: work that never needed a screen now runs as a direct call. The same math holds for AI voice agents on a telephony integration: model the deflected minutes and freed rep hours by volume, handle time and the Flex Credits each automated interaction consumes.

Leave room in the cost side for agent metering. Salesforce has said that, once agents are registered, each successful MCP or direct API call they make will count as a Headless Platform Interaction and draw down Flex Credits. As reported by Salesforce Ben, agentic usage is not metered yet, customers get 30 days' notice before billing starts, the per-interaction rate has not been published, and sandboxes, scratch orgs and Developer Edition orgs are excluded. Model call volume per process now, because a chatty agent that loops through discover and describe on every request will cost more than one that reuses what it already knows.

Where does a Salesforce PDO or Agentforce partner fit?

Adopting headless MCP safely is a governance project as much as a build. A Salesforce PDO (Product Development Outsourcer) builds commercial apps on the platform, packages them correctly and shepherds them through AppExchange security review. That skill set maps directly onto headless MCP: an ISV exposing its product as MCP tools needs someone who can design the tool surface, enforce the running-user model and pass review the first time. An Agentforce partner does the same for an internal agent, wiring the four tools to real business logic rather than a demo. When you evaluate either, weigh three things:

Do they design the permission model first, or bolt it on after the demo works?
Can they show real headless agent work against a governed org, not slideware?
Do they own integration, packaging and the security review, or hand you off midway?

That combination of platform depth and governance discipline is what Tekunda brings to headless projects, and we run it in production today, not on a roadmap. Our Salesforce services team maps the safe path for your org, from tool surface to security review.

FAQ

What is the Headless 360 MCP Server?

It is Salesforce's hosted MCP endpoint that lets Agentforce, Claude, ChatGPT, Cursor and other clients discover and invoke platform skills through four tools: discover, describe, dispatch and dispatch read only.

Is the Headless 360 MCP Server generally available?

Not yet. It has been in open beta since July 2026, while the standard hosted MCP servers have been generally available since April 2026, so pilot it before you commit critical flows.

Does an agent using headless MCP bypass Salesforce security?

No. It runs as an authenticated user with the mcp_api scope, and CRUD, field-level security, sharing rules and permission sets are all enforced.

Will Salesforce charge for MCP calls?

Salesforce plans to meter each successful call by a registered agent as a Headless Platform Interaction paid in Flex Credits. It is not metered yet, and customers get 30 days' notice first.

Where should we start?

Enable a read-only server in a sandbox, connect one client, confirm the permission model behaves, then widen scope. Bring in a partner if governance is not your team's core skill.

Headless MCP is how agent-driven work reaches Salesforce, and the Headless 360 MCP Server is already in open beta. If you want that surface to move fast without widening your attack surface, that is the build and security work Tekunda does every day. Book a short scoping call.

Salesforce Integration Patterns for Growing Companies

Tekunda Team — Fri, 06 Nov 2026 12:00:00 GMT

TL;DR: Salesforce documents six core integration patterns, from request and reply to data virtualization, and a growing company rarely needs all of them on day one. Start with a few well-governed API integrations, move record changes onto events as volume rises, and put an API or agent layer in front of Salesforce once many systems and AI agents need the same data.

Most guides list the patterns and stop. The harder question for a scaling team is sequencing: which pattern to adopt at which stage, and what to retire before it breaks. That is what this guide covers, including the new agent layer Salesforce opened with Headless 360.

What are Salesforce integration patterns?

An integration pattern is a reusable answer to a recurring question: how data or a process should move between Salesforce and another system, and how fast. Salesforce's Integration Patterns and Practices guide names six:

Request and reply: Salesforce calls a remote system and waits for the answer.
Fire and forget: Salesforce sends a message and carries on without waiting.
Batch data synchronization: large record sets move on a schedule.
Remote call-in: an external system creates, reads or updates Salesforce data.
UI update based on data changes: the screen refreshes when the underlying records change.
Data virtualization: external data is shown in Salesforce without being stored there.

Which integration pattern fits which job?

A credit check or price quote before a user can continue: request and reply.
An order is placed and the ERP needs to know: fire and forget, ideally through events.
A nightly finance or warehouse load: batch synchronization with Bulk API 2.0, which Salesforce's architects describe as well suited to extracting thousands of records efficiently.
A web store or portal writing leads and cases: remote call-in through the REST API.
Large external tables users only need to read: data virtualization with Salesforce Connect, so nothing is replicated.

For ERP-heavy estates, our guide to Salesforce and SAP integration patterns for manufacturers walks through these choices with order, pricing and inventory flows.

Point-to-point, hub or API-led: which architecture should a growing company choose?

Let the number of systems and consumers drive the architecture, not the size of the ambition.

A handful of systems: direct point-to-point integrations are fine, as long as each has an owner, a dedicated integration user and logging.
The same data needed in several places: introduce a hub or middleware, so one change does not ripple through every connection.
Several teams consuming the same data: move to API-led connectivity, where system, process and experience APIs separate concerns and get reused.

We cover the scaling logic in more depth in Salesforce integration architecture patterns that actually scale.

When should you move to event-driven integration?

Move when polling and chained callouts start to hurt: duplicate updates, timeouts, or downstream systems that always lag behind. Salesforce's event-driven architecture decision guide is clear on the tools:

Change Data Capture publishes record creates, updates, deletes and undeletes to other systems.
Platform Events carry custom payloads you define, published from APIs, Apex or Flow.
Pub/Sub API is the recommended choice for any new publish and subscribe integration.
Events can be replayed for three days, and each payload is capped at 1 MB.

The same guidance steers new work away from outbound messages and PushTopic. If you still run them, plan the migration before volume forces it.

What is headless MCP, and what does Headless 360 change?

Headless MCP means reaching Salesforce data, logic and workflows through APIs and Model Context Protocol servers instead of the browser UI. Salesforce announced Headless 360 at TDX on April 15, 2026, exposing platform capabilities as APIs, MCP tools and CLI commands, with more than 60 new MCP tools at launch. In August 2026 it expanded the program with a Headless 360 MCP Server and a Data 360 MCP Server that agents on Agentforce, Claude, ChatGPT and Cursor can use.

For integration teams this adds a new consumer: AI agents that discover and call capabilities at runtime. They need the same discipline as any integration, with least-privilege users, audited actions and clear ownership. Our guide to connecting AI agents to Salesforce safely with MCP covers the controls. Tekunda is first and only in headless CRM plus MCP, and first to run agent-to-agent (A2A) and SWARM orchestration in production, so this is work we already run for clients.

What do growing companies get wrong?

Replicating everything. Salesforce's data integration decision guide says to avoid unnecessary replication. Virtualize or call APIs where data can stay put.
Sharing a human login. Use a dedicated API-only integration user and External Client Applications for authentication.
Treating admin tools as strategy. Data Loader and the Salesforce CLI are for data stewardship, not a base for integrations.
No change control on integration metadata. Named credentials, event definitions and field mappings drift fast. Treat them like code, as covered in metadata governance for growing orgs and teams.

How does Tekunda help growing companies integrate Salesforce?

Tekunda is a certified Salesforce SI, ISV, PDO and Agentforce partner, and an Anthropic (Claude) partner. We design an integration roadmap that fits your current stage, then extend Salesforce with event-driven flows, reusable APIs and MCP-connected agents as you grow. See how we approach Salesforce integration, or start from the Tekunda homepage.

FAQ

What is the simplest Salesforce integration pattern to start with?

Request and reply, where Salesforce calls another system and waits for the response. It suits low-volume lookups but should not carry bulk loads.

Do I need MuleSoft to integrate Salesforce?

No. Native APIs, events and Salesforce Connect cover many needs. Middleware such as MuleSoft pays off when many systems and teams share integrations, and it needs its own license.

What is the Headless 360 MCP Server?

It is a Salesforce MCP server that lets authorized AI agents discover and invoke Salesforce capabilities through the open Model Context Protocol. Check Salesforce's documentation for its current release status.

Should new integrations use outbound messages?

No. Salesforce recommends the Pub/Sub API for new publish and subscribe work and does not plan further investment in outbound messaging.

How to Build a Successful Software Team

Andrew Hanna — Fri, 30 Oct 2026 05:41:57 GMT

Building a successful software team takes more than technical skill. From our own delivery work, success comes from three things: dealing with common technical problems directly, giving people real ownership, and hiring people who grow with the team. This guide covers each one, then lists the research-backed resources we use to measure and improve how a team works.

Common Technical Challenges

Every software team runs into problems that stall progress if left unmanaged:

Feature fragmentation: features built without a shared strategy create inconsistent products, especially when releases are rushed or decisions are made in silos.
Code duplication: repeated logic across a project adds technical bloat and conflicting updates, most common in fast-growing teams.
Overly complex designs: over-engineered architecture limits speed and experimentation. Clean, scalable abstractions beat trying to future-proof every edge case.
Maintenance overhead: unstandardised environments and tightly coupled dependencies turn maintenance into firefighting instead of improvement.
Slow feedback loops: manual testing and blocked deployments delay business value and frustrate teams.
Lack of visibility: without clear ownership and traceability, teams duplicate work and struggle during incidents or audits.

Strategies That Work

We address these challenges with a few consistent practices:

Modular, reusable design: breaking systems into smaller components and following atomic design principles to keep UI components consistent.
Clean, maintainable code: peer reviews, automated tests, and scheduled refactoring, enforced with tools like ESLint, Prettier, and SonarQube.
Cross-functional collaboration: designers, developers, testers, and stakeholders align early using shared tools like Miro and Notion.
Clear team boundaries: each team owns a well-defined slice of the product, so handoffs and waiting on other teams stay the exception.
Agile, disciplined workflows: iterative development with regular feedback loops, backed by real backlog grooming, not chaos.

Breaking Free from “What Worked Last Time”

Long-standing teams often default to known approaches instead of asking what the best solution is now. That is efficient short-term but damaging once business requirements outpace the systems supporting them. Dynamic thinking keeps teams resilient: use code reviews for mentorship, not just nitpicking, revisit old features with a critical eye, and let engineers call ad hoc brainstorming sessions instead of waiting for the next retrospective. Leaders who protect time for experimentation, even one sprint per quarter, give the team room for its biggest breakthroughs.

New tools need the same thinking. DORA's 2025 research, published as the State of AI-assisted Software Development, describes AI's main role as an amplifier of an organization's existing strengths and weaknesses. Adding AI tools to a team with weak practices will not fix the practices.

Ownership, Trust, and Team Culture

Ownership is what keeps people invested. It starts with direct, simple stakeholder relationships: invite engineers into roadmap reviews, replace gatekeeping with direct access to domain experts, and explain the reasoning behind priorities. Engineers who understand the customer make better calls, which is the same principle behind creating exceptional customer experiences.

Trust follows. Google's study of 180 teams, summarized in its re:Work team effectiveness guide, found five dynamics that set effective teams apart: psychological safety, dependability, structure and clarity, meaning, and impact. Psychological safety came first. In practice, that means letting junior team members own a small feature end to end with a senior shadowing, not correcting. It also means celebrating wins publicly through demos and shoutouts. A good sign is someone saying “I tried this approach, here’s why” before anyone asks.

At the team level, ownership means collaboration over competition: pair programming, shared feature ownership, and cross-team reviews. Align personal growth with team goals in 1:1s, so a developer interested in DevOps can lead a CI/CD project. Culture also lives outside the sprint board: regular tech talks and team-building days, like our Freaky Friday sessions, give people a low-stakes place to share what they learned.

Hiring and Growing the Right People

Hiring is not about filling a seat, it is about finding people who strengthen team dynamics and bring long-term value. Engagement is the risk to manage: Gallup's State of the Global Workplace data for 2025 puts only 20% of employees worldwide as engaged, with 64% not engaged and 16% actively disengaged. In interviews, watch how candidates think, not just what they know: how they handle unknowns, and whether they understand context before acting.

Rotational internships help both sides find the right fit, exposing interns to product, support, ops, and engineering in one cycle. Career paths should not be rigid either: support internal mobility so people who outgrow a role stay with the company in a new one, instead of leaving altogether.

Resources for Software Teams

These are the frameworks and references we return to when diagnosing or growing a team. All are free to read and grounded in research rather than opinion.

DORA metrics: five delivery measures split into throughput (change lead time, deployment frequency, failed deployment recovery time) and instability (change fail rate, deployment rework rate).
SPACE framework: a 2021 model from GitHub, Microsoft and University of Victoria researchers covering satisfaction, performance, activity, communication and efficiency. Its core point is that productivity cannot be reduced to one metric.
Team Topologies: Matthew Skelton and Manuel Pais's model of four team types (stream-aligned, enabling, complicated subsystem, platform) and three interaction modes (collaboration, X-as-a-Service, facilitation).
Google re:Work team effectiveness guide: the five dynamics from Google's team research, with survey questions you can run on your own team.
Conferences and communities: events are where teams pick up ideas that do not reach blog posts yet, as we found at Web Summit Lisbon 2025.

Putting It Into Practice

Encourage knowledge sharing: rotate ownership of weekly demos or tech talks so junior members contribute too.
Invest in tooling: version control, CI/CD, and AI-assisted tools like GitHub Copilot or internal AI agents cut boilerplate and review overhead, provided the underlying practices are sound.
Plan for scalability: build modular, cloud-native systems from the outset instead of short-term fixes.
Run real retrospectives: use them to fix root causes, not just symptoms. One internal fix came from noticing repeated staging failures, solved with pipeline step retries and health checks.
Fund continuous learning: reserve budget and time for quarterly hackathons focused on tooling and side projects.
Track a balanced set of metrics: pair DORA's delivery measures with at least one signal of developer satisfaction, as SPACE recommends, so speed never hides burnout.

Conclusion

A successful software team is not built by rigid execution. It is built by how well it handles technical challenges, how genuinely it distributes ownership, and how carefully it hires and grows people. Every improvement compounds: reusable code, clear ownership, and the right hire all reinforce each other over time. If you want an experienced team to build alongside yours, or to help set these practices up, talk to Tekunda.

FAQ

What are the best resources for software teams?

Start with DORA's metrics guide for delivery, the SPACE framework for productivity, Team Topologies for structure, and Google's re:Work guide for team dynamics. All are free and research-based.

What metrics show a software team is healthy?

DORA's five metrics cover throughput and instability: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. Pair them with a satisfaction measure, since no single metric captures productivity.

What makes a software team effective?

Google's research on 180 teams found psychological safety mattered most, followed by dependability, structure and clarity, meaning, and impact. Who is on the team mattered less than how they work together.

How do you give junior engineers real ownership?

Let them own a small feature end to end with a senior shadowing rather than correcting. Ownership shows when someone explains their reasoning before anyone asks for it.

What should you look for when hiring engineers?

How candidates think, not only what they know: how they handle unknowns, and whether they gather context before acting.

Salesforce Security Review Checklist: What to Fix, In Order

Tekunda Team — Sun, 25 Oct 2026 05:48:04 GMT

A Salesforce security review checklist is only useful if it is ordered. Most submissions fail on a short, predictable list, and access control sits at the top of it. Work in this order: enforce user-mode access in code, triage the three scanner reports, then assemble the submission materials and a test environment the reviewer can actually use. Salesforce puts a typical review at 4 to 5 weeks, so a rejection costs you a release cycle, not an afternoon.

Tekunda has taken managed packages through the review in healthcare, logistics and manufacturing. What follows is the order we work in, not a description of the process. For the end-to-end submission journey, see How ISVs Pass the Salesforce AppExchange Security Review.

The checklist at a glance

Confirm what you are submitting: a managed package, plus every external service it touches.
Fix access control: user mode, explicit sharing, no injectable SOQL.
Fix output handling, secrets, transport security and authentication.
Run Code Analyzer, the Partner Security Portal source scan and a DAST scan.
Fix what each scanner's bar requires, and document every false positive.
Package the documentation, credentials and a working test org.
Submit from the Partner Console and plan for the annual re-review.

What changed in 2026

Three things moved this year, and older checklists predate all of them.

The marketplace is now AgentExchange. Salesforce renamed AppExchange to AgentExchange at TrailblazerDX 2026 and folded the Slack Marketplace into it. Salesforce's own Trailhead material now uses the new name, but the security review itself is still the gate to a listing.
Apex API version 67.0 changes the security defaults. Per Salesforce's Summer '26 architect highlights, database operations now run in user mode by default, classes without a sharing declaration default to with sharing, and WITH SECURITY_ENFORCED is removed, so a class still using it on v67.0 will not compile. Triggers are the exception: they always run in system mode.
You run the dynamic scan yourself. Salesforce's preparation guidance now recommends OWASP ZAP or Burp Suite Enterprise Edition for external endpoints and accepts your preferred DAST scanner. See Running Your Own Dynamic Scans After Chimera for the tools and the report to submit.

Step 1: Confirm what is in scope

Salesforce's guidance is blunt that all of your solution's components and services, no matter where they live, are fair game. That means the package, any web service it calls, any site that stores Salesforce data, and any mobile or desktop client. Settle your package type before you start fixing code, because it decides what you upload; Salesforce Packaging Models for ISVs: 1GP vs 2GP vs Unmanaged covers that choice.

Step 2: Fix the findings that get submissions rejected, in order

Fix these top to bottom. The items near the top are both the most common findings and the most expensive to retrofit, which is why leaving them until last is how a submission slips a cycle.

Access control that is not enforced in user mode. Every query and DML operation has to respect the running user's object permissions, field-level security and sharing. Do not rely on the v67.0 default alone: a package usually carries classes on older API versions, and trigger handlers can be entered from a trigger running in system mode. Set the access mode explicitly with WITH USER_MODE on SOQL and AccessLevel.USER_MODE on Database calls, and replace any remaining WITH SECURITY_ENFORCED before you bump the API version.
Sharing declared on the wrong classes. Below v67.0, a class with no sharing keyword inherits sharing from its caller, so a helper invoked from an @AuraEnabled method can quietly run without it. Declare with sharing, without sharing or inherited sharing explicitly on every class, including inner and utility classes, so the reviewer never has to work out which default applies.
Dynamic SOQL assembled from input. Use bind variables. If a query genuinely has to be built as a string, escape every interpolated value and keep that escaping visible in the same method, because that is where a reviewer reads it.
Unescaped output. Anything reaching the page through escape="false", lwc:dom="manual" or innerHTML has to be sanitised before it gets there, not after.
Secrets and customer data in the wrong place. Hardcoded keys in Apex, tokens in unprotected custom settings, a record with personal data passed to System.debug. Named Credentials and protected custom metadata are what reviewers expect instead.
Weak transport or storage encryption. Salesforce's list of the most common review findings requires TLS 1.2 on connections involving your sites and portals, and the team scans every external endpoint for it. Encrypt anything you store off-platform as well.
External systems authenticated with a stored username and password. Use OAuth for every connection your package opens to a service you or the customer runs. Stored credentials are a finding on their own, and they make the data flow document harder to defend.
A composite site shipped without the basics. If your solution includes a web surface outside the org, it needs security headers, and its cookies need Secure and HttpOnly. Reviewers check the site you hand them, not the one you describe.
External endpoints nobody scanned. If your package calls a service you operate, that service is in scope and needs its own dynamic scan report.
A test environment the reviewer cannot use. An expired org, an identity challenge that locks them out, or objects with no data in them. Salesforce tells partners to treat the review team as a potential customer test-driving the whole solution end to end, and it cannot review what will not run.

Step 3: Run the scanners and meet each one's bar

You must include a Salesforce Code Analyzer report, a Partner Security Portal source scanner report and a DAST report. The bar is not zero findings, and it is different for each scanner:

Salesforce Code Analyzer: fix all security-related findings and errors except false positives, and ignore findings that are not security related. It does not scan external endpoints.
Partner Security Portal source scanner (Checkmarx): fix Low, Medium and High findings, and leave informational warnings alone.
DAST scanners such as ZAP, Burp Suite, Veracode Dynamic Analysis, Intruder and Acunetix: fix everything except informational items and warnings, then attach a screenshot proving the right external endpoint was scanned.

Generate the Code Analyzer v5 report with the AppExchange rule selector, so it matches what the reviewer expects. On a complex codebase the run can take hours:

sf code-analyzer run --rule-selector AppExchange --rule-selector Recommended:Security --output-file CodeAnalyzerReport.html

Which scans are mandatory has shifted more than once, so confirm the current scanner requirements before you generate anything.

Step 4: Document every false positive

Across our submissions, four categories come back as genuine false positives often enough to plan for: access-control findings raised against code that already enforces user mode, sharing findings on classes only ever entered through a context that has applied sharing, retired-library findings matched on a version string inside a bundled static resource, and reflected cross-site scripting findings on parameters that never reach the DOM.

Being right is not enough, though. The document is what passes. Salesforce asks for a document explaining why each flagged item does not pose a security risk, and tells you to be specific about how you protect against the vulnerability indicated. Give every finding its own entry: scanner and rule identifier, file and line, one sentence describing the data path, the exact control that protects it, and where that control lives in the package. One-line dismissals come back as questions, and questions cost weeks. For the justification format and the mistakes that get it rejected, see How to Document False Positives for the Salesforce Security Review.

Step 5: Assemble the submission materials

Usage documentation written so that someone who has never seen the app can complete a full workflow.
Data flow documentation between the Salesforce org and any composite site, mobile app or browser extension.
Every scan report, the DAST endpoint screenshot and the false positive document.
A Developer Edition org with the package installed and realistic seeded data.
Credentials for each external system the app touches, or a hosted test instance of it.
Install links and credentials for any mobile or desktop client.

You then start the review from the Publishing Partner Console: open the Technologies tab, choose Start Review on your solution, and complete the contacts, technical details, documentation and test environment sections before payment.

How long does the security review take, and what does it cost?

Salesforce states that a solution typically takes 4 to 5 weeks to get through the review, and that for every paid solution there is a $999 fee for the initial submission and for any subsequent attempts. If the team finds vulnerabilities, you fix and resubmit, and that counts as another attempt. Salesforce also notes that most submissions pass on the second attempt. Both facts argue for the same thing: front-load the access control work, because the cheapest submission is the one you only have to make once.

If you would rather the review was handled by people who have cleared it before, Tekunda runs AppExchange security review preparation as a Salesforce partner. If you are still weighing whether to bring in outside help, What a Salesforce PDO Does, and When to Hire One sets out where a PDO earns its fee.

FAQ

Do free apps need a security review?

Yes. A solution has to pass the review before it is listed on the marketplace. The $999 submission fee that Salesforce documents applies to paid solutions.

Does API version 67.0 mean I can skip CRUD, FLS and sharing work?

No. The new defaults only apply to classes compiled at v67.0 or later, and triggers still run in system mode. Declare access modes and sharing explicitly so the reviewer can verify them line by line.

Is Salesforce Code Analyzer enough on its own?

No. You also need the Partner Security Portal source scanner report, and any external endpoint your app calls needs a DAST report of its own.

Does an Agentforce or agent-based app change the checklist?

The same review applies, but every external service your agent can call has to be described and scanned. See AppExchange Security Review for Agentic Apps: What Is Different.

Is the security review a one time event?

No. Listed solutions are typically re-reviewed once a year, and Salesforce can request a review at any time. New package versions use an attestation in the Partner Console instead of a fresh review, so keep the checklist as a standing release gate.

Agentforce ROI Calculator: How It Works and What It Really Costs (2026)

Tekunda Team — Sat, 24 Oct 2026 05:48:14 GMT

TL;DR: An Agentforce ROI calculator estimates the three-year net benefit of Salesforce AI agents: the labour you save, minus what the agents cost to run in Flex Credits. Salesforce's official calculator is free and quick, but it runs on built-in assumptions (a fixed per-case agent cost, a 70% year-on-year ramp) and excludes implementation, licences, and Data 360. Read its benefit line as a ceiling and its cost line as a floor. Run your own numbers on our Agentforce ROI calculator, then use this guide to turn the estimate into a figure you can defend.

What is the Agentforce ROI calculator?

The Agentforce ROI calculator is Salesforce's free, no-login tool for estimating the financial return of deploying Agentforce agents. You pick use cases, enter a few operational numbers, and it returns a year-by-year view of productivity benefit, agent cost, net benefit, and the Flex Credits you would consume. Salesforce labels the output as illustrative only, and states that implementation costs, Salesforce licences, and Data 360 credits are not included.

Two versions are now in circulation. Some regional editions of the official ROI calculator still show the classic three-year ROI model. The US page has been reworked toward a first-year pricing estimate built from seats, actions per agent template, and Data 360 inputs, rounded up to the nearest 100,000 credits. If you searched for an ROI figure and got a price, that is why. Partners publish their own variants; ours focuses on support teams and estimates ticket deflection, freed headcount, and payback from numbers you already know.

How does the Agentforce ROI calculator work?

The three-year model follows the same three steps for every use case:

Pick your use cases. The presets are Customer Service, Sales Development Rep, Sales Coach, Field Service and Back Office, Employee Help in Slack, Loan Product Assistance, Quoting, and Customer Insights in Slack. Each has its own action profile, so a service agent and an SDR agent produce very different math.
Enter your numbers. Headcount, salary, volumes (cases per rep per day, leads per rep per week, quotes per week), and a year-three target for the share of work agents absorb. Sales presets add conversion rate, deal size, close rate, and gross margin.
Read the projection. You get productivity benefit by year, agent cost, net benefit, the cost of doing nothing, total Agentforce investment, and an estimated Flex Credit total.

The assumptions the calculator makes for you

The inputs you type are only half the model. The other half is a set of built-in defaults that Salesforce discloses on the page but most users never read:

Customer Service: each agent-handled case costs about $0.30, and adoption ramps so year one is 70% of year two and year two is 70% of year three.
Appointment Scheduling: about $0.43 per scheduled appointment, based on 4 to 5 actions.
Employee Help in Slack: agents resolve 30% of questions in year one, 40% in year two, and 50% in year three, at $0.20 per task.
Sales Development Rep: about $0.84 per lead, with untouched leads converting to qualified leads at 50% in year one, 75% in year two, and 100% in year three.
Quoting: a 20% efficiency gain at $0.40 per quote.

Those per-unit costs are the real lever. If your agent takes twice the actions Salesforce assumes, your cost line doubles while the benefit line stays put. The year-three target matters just as much: a 50% target and a 20% one produce very different paybacks, so anchor it to a small pilot rather than a vendor default. Check which of these inputs the headline number quietly depends on.

How is Agentforce priced in 2026?

You cannot trust an ROI number without understanding the meter behind it. According to Salesforce's pricing page, Agentforce is sold in four ways:

Flex Credits: $500 per 100,000 credits. A standard or custom action uses 20 credits (about $0.10) in production and 16 in a sandbox, and an Agentforce Voice action uses 30 credits (about $0.15). Prompts run through Salesforce-enabled models also consume credits, from 2 for a basic prompt to 16 for an advanced one, per the Flex Credits rate card.
Conversations: a flat $2 per conversation, regardless of how many actions it contains.
Per-user add-ons: $125 per user per month for Sales, Service, and Field Service, and $150 for Industries clouds. A $5 Agentforce User License is also listed, which requires Flex Credits.
Editions: in September 2026 Salesforce replaced its edition lineup with Core ($195 per user per month, 500,000 Flex Credits), Advanced ($395, 1 million credits), and Max ($550, 2.75 million credits). Max takes over from Agentforce 1 Edition at the same price, and existing Agentforce 1 customers can move to it at no extra cost.

The break-even between the two consumption models is simple arithmetic: $2 buys 20 standard actions at $0.10 each. A conversation that takes 5 to 15 actions costs $0.50 to $1.50 on Flex Credits, so short, deterministic agents favour credits and long, multi-step sessions can favour the flat rate. If your calculator assumes a single per-conversation price, its cost line is wrong in one direction or the other.

Three more lines belong in the model. Enterprise Edition customers and above can get 100,000 Flex Credits free through Salesforce Foundations, according to Salesforce Help, which is enough to prototype before you commit. Customer-facing agents in Salesforce's estimator include an assumption of 10% sandbox credit use, so testing is not free. And Data 360 consumption is billed separately from the agents. Salesforce marks all of this pricing as subject to change, so recheck before you put a figure in front of finance. Each model shifts the payback month differently.

Can you estimate the ROI of AI-powered phone agents like Agentforce?

Yes, and it is worth doing as its own line, because a voice action costs 50% more than a standard one. You model call volume and average handle time the way you would cases, but you price credits against voice actions and count actions per call rather than per chat.

The calculator assumes the telephony is already in place. In practice a phone agent needs a CTI layer that brings call routing, logging, and live caller context into Service Cloud so the agent has something to act on. Budget that integration and its per-seat licensing separately, or your phone-agent payback will look better on paper than in the bank.

What does the Agentforce ROI calculator leave out?

Every calculator shares one blind spot: it prices the software, not the project. The number assumes the agents are already built, integrated, and trusted. Six costs live outside the tool, and together they often outweigh the software line:

Data readiness and Data 360. Agents are only as good as the records they read, so deduplication, field hygiene, permissions, and grounding are real line items. Data 360 is optional for agents that only need native CRM data, but required once an agent needs unified or unstructured data, and Salesforce excludes its credits from the ROI output.
Implementation labour. Topics, actions, instructions, guardrails, testing, and rollout. Some use cases are a few clicks; others need custom actions and Apex, and the calculator does not know which you face.
Integration. Every system an agent must read from or write to (telephony, billing, ticketing, ERP) is a small project of its own, not a checkbox.
Change and adoption. Salesforce's own disclaimer names implementation practices and user adoption as factors in actual results. A deflection target you never train your team to hit is fiction.
Governance and security. Audit, privacy alignment, and agent monitoring are recurring work, not a one-time setup.
Attribution. Isolating the agent's impact from concurrent staffing or process changes needs a measured baseline, not a projection.

The gap between an agent as a demo and an agent as a dependable decision-support platform is exactly where projects stall; we wrote about closing it in what it takes to drive ROI from AI agents.

How do MCP and headless agents change the integration line?

The biggest recent shift in that integration line is the Model Context Protocol (MCP), the open standard for connecting agents to tools and data. Salesforce announced MCP support across its platform in June 2025, including a native MCP client for Agentforce, and its MCP gateway adds a central server registry, access controls, and rate limiting. In April 2026 it launched Headless 360, which exposes core Salesforce functions as APIs, MCP tools, and CLI commands, with more than 60 new MCP tools at launch. The new Max edition is slated to include an allocation of Headless 360 capacity.

For an ROI model, that means an agent can reach external systems through one standard handshake instead of a bespoke connector per system, and agents can run inside your own product or workflow rather than only inside the Salesforce UI. Done right, it lowers the per-connector build cost older ROI models never captured, but only when your data and permissions are already in order. Tekunda is the first and only firm delivering headless Salesforce with MCP in production, building the MCP servers and the headless CRM implementation together. We cover the adoption path on our headless MCP on Salesforce page.

How do you turn the estimate into a number you can defend?

Treat the calculator output as step one, then do four things:

Capture a real baseline first. Average handle time, interaction volume, cost per interaction, resolution rate, and escalation rate. A calculator that starts from a guessed baseline returns a guessed ROI, and every post-launch gain should be a measured delta against these numbers.
Right-size the automation target. Replace the default year-three target with what a pilot actually achieved on your case mix and knowledge coverage. We cap our own estimate at a deflection we have sustained in production (see our ASSA ABLOY engagement), not a marketing best case, because an inflated rate produces a payback no one hits.
Replace the per-unit cost with a real action count. Count the actions a representative conversation takes, price them against the billing model you will run, add sandbox testing and prompt consumption, then add Data 360 if your agents need it.
Put the project in the investment line. Integration, data preparation, and change management belong there, and payback should be the month cumulative savings overtake cumulative spend, not a three-year total.

The result will almost always be smaller and later than the calculator's figure. That is the point: a conservative number that lands is worth more than an optimistic one that gets the programme cancelled in year two.

Do you need a security review or a Salesforce PDO?

For an internal Agentforce rollout, no AppExchange security review applies; that gate is for managed packages listed on the AppExchange. If you are an ISV building an agent-powered product to sell, it does apply and it belongs in your model: a paid submission fee, a code and behavioural audit against secure coding practices, and scans you now run yourself since Salesforce retired its hosted Chimera scanner. Working through the security review checklist up front is far cheaper than a failed submission.

That distinction also decides the partner type you need. A system integrator implements Salesforce inside your business; a Salesforce PDO (product development outsourcer) designs, builds, and maintains commercial AppExchange apps and shepherds them through the review. Internal rollouts want implementation depth; an ISV shipping an agent-powered product wants PDO experience.

How do you choose an Agentforce implementation partner?

A calculator gives you a target; a partner gets you there, and the calculator's blind spots are exactly where that partner earns its fee. Ask for specifics on four things: an agent they shipped to production, not demoed; how they integrated it; the deflection they actually measured; and whether they price against current Flex Credit and edition rates rather than a stale spreadsheet. Then ask them to rebuild the estimate with your real data before you sign anything.

The calculator also cannot tell you whether to configure Agentforce or build a custom agent: standard use cases with clean data favour configuration, while deep, differentiated workflows sometimes justify a custom build. We lay out that decision in Agentforce vs custom AI agents. Either way, Tekunda builds, integrates, and ships the agents behind these numbers, which is why our estimates start conservative. See how we approach Agentforce, or talk through your numbers once the estimate is worth acting on.

FAQ

Is the Agentforce ROI calculator free?

Yes. Salesforce's official calculator and Tekunda's are both free and return an estimate without a purchase.

How accurate is the Agentforce ROI calculator?

It is directional. It relies on built-in per-unit costs and ramp assumptions and excludes implementation, licences, and Data 360, so pressure-test it against a pilot.

How much does an Agentforce action cost?

A standard action uses 20 Flex Credits, about $0.10 at $500 per 100,000 credits. A voice action uses 30 credits, about $0.15.

Should I use Flex Credits or the $2 conversation model?

Below roughly 20 standard actions per conversation, Flex Credits are cheaper; above it, the flat $2 rate can win. Model both against a real action count.

Does the calculator include Data 360 costs?

No. Salesforce excludes Data 360 credits from the ROI output, so add them yourself if your agents need unified or unstructured data.

Salesforce Asset Lifecycle Management for Connected Devices

Tekunda Team — Fri, 16 Oct 2026 06:00:12 GMT

Short answer: Salesforce Asset Service Lifecycle Management (ASLM) is Salesforce's packaged set of features for servicing a physical asset from installation to retirement: an interactive asset hierarchy, a coverage view of entitlements, work order estimation, recall and upgrade campaigns, exchanges, depot repair and service inventory, all built on the standard Asset object. It works when each installed unit is one Asset record that service, warranty and renewals all read. For connected devices, the hard part is telemetry, because device events must not land in the org row by row.

What is Salesforce Asset Service Lifecycle Management?

Salesforce describes ASLM as a way to "manage the entire lifecycle of asset service operations" (Salesforce Help). In practice it groups into five capability areas:

Asset visibility. Asset Interactive Hierarchy shows parent and child assets, and Asset Coverage View puts a customer's entitlements in front of the agent.
Service execution. Work Order Estimation prices work before it starts, Book Service Appointment handles scheduling, and Product Service Campaign runs large-scale recalls and upgrades.
Returns and repair. Advanced Exchange creates return and replacement requests, Depot Repair handles units sent back for repair, and Service Parts Return covers damaged parts tied to work orders.
Service inventory. Inventory allocation, batch management, search and transfer, counts and replenishment.
Labour and AI. Timesheets and Labor Cost Optimization, plus Agentforce for ASLM, which provides agent templates for inventory tasks and service estimation.

The short version: standard Salesforce gives you the asset and its coverage, and ASLM adds the service operations that run around it.

Which clouds and licences does ASLM need?

According to the same Help article, ASLM is available in Lightning Experience in Service Cloud, Manufacturing Cloud, Automotive Cloud, Communications Cloud, Consumer Goods Cloud, Energy and Utilities Cloud and Media Cloud. Some features need add-on licences, bought through Salesforce Go, so check the editions table for each feature before you plan around it.

Two related products are easy to confuse with it. When Salesforce announced ASLM in June 2024 as a separate add-on, it also announced Connected Assets, a separate add-on for acting on two-way telematics events such as firmware updates, work order creation or safety alerts, and an Asset Health Score for Field Service (Futurum Group). ASLM is the service layer. Connected Assets and your own integration are the telemetry layer.

Which object should hold what?

None of those features help if the data model underneath is wrong. Most failed connected-asset programmes we are called into failed here, not in the integration. A clean split looks like this.

Product2 is the model. It is what you sell, not what the customer has.
Asset is the individual unit: serial number, install date, status, account, contact and location. Use the parent and root asset fields to model a device that sits inside a gateway, a panel or a building, so a fault on a component rolls up to something a technician can be dispatched to. This is also what the interactive hierarchy draws.
WarrantyTerm defines what is covered, meaning labour, parts and expenses, and AssetWarranty attaches that term to a specific unit with its own dates (object reference).
Entitlement and ServiceContract carry what the customer bought and until when. Entitlements can hang off the account, the asset, the case or the contract, which is exactly why teams end up with the same coverage recorded in three places, and why the coverage view shows conflicting answers.
Case and WorkOrder reference the asset, never the product. A case without an asset id is a case you cannot bill, cover or trend.

One rule keeps this honest: coverage is asserted in exactly one place, and everything else reads it. If sales can edit a renewal date that service does not see, you do not have asset lifecycle management, you have three spreadsheets in a trench coat.

How do you get device telemetry in without drowning the org?

Salesforce retired IoT Explorer and pointed customers at platform events and flows instead (retirement notice). That is the right instinct, but it needs a rule attached: Salesforce stores state and decisions, not the raw stream.

In practice we run three layers.

Ingest and reduce outside the org. Heartbeats, readings and duplicate alarms are collapsed into meaningful transitions before anything crosses the API boundary.
Publish transitions as platform events. One event per state change, carrying the serial number, the condition and the timestamp, resolved to the Asset by serial rather than by record id. The integration user that publishes them usually authenticates through a connected app, so review it against the Salesforce connected app security changes before go-live.
Write derived state onto the Asset, and let automation decide. Current health, last seen, firmware version, open fault. A flow or Apex handler then decides case, work order, or nothing at all.

That last option matters most. The triage rule, not the ingestion, is what keeps a connected fleet serviceable. For ASSA ABLOY, across FocusCura and Phoniro, we run 11,000 connected devices producing up to 2.5 million events a week and cut weekly cases from 3,000 to 350, a 93% reduction across three markets with no added support staff. The devices did not get quieter. The model stopped creating a case for every symptom. The full breakdown is in how connected-device teams cut support cases by 93 percent on Salesforce.

What does one asset record actually buy you?

Service sees coverage before dispatch, so nobody sends a paid technician to a unit under warranty.
Warranty claims resolve against the term attached to that unit, not against a policy someone remembers.
Recalls and upgrades target the right units, because a product service campaign can only reach assets that carry a real model, serial and firmware version.
Renewals are forecast from install dates and warranty end dates that are already in the system, so expiries stop being discovered by the customer.
Product teams get failure rates per model and per firmware version, because every case points at a real unit.

None of that needs an AI layer to be worth doing. It does make the AI layer possible later, because an agent can only reason about an installed base that is actually modelled.

How should you sequence the build?

Load the installed base with real serial numbers and install dates, even if it is partial. Assets without serials cannot be reconciled later.
Model the hierarchy before automating anything, because rework here touches every downstream record.
Attach warranty terms and entitlements, and pick the single object that owns coverage.
Wire telemetry as state transitions, with a written triage rule per condition.
Only then switch on ASLM features such as estimation, campaigns and exchanges, along with service contracts, renewal forecasting and agents.

Teams that reverse steps one and four end up with a beautiful integration writing events onto assets nobody trusts. If you want this reviewed against your own org, see how Tekunda delivers asset lifecycle management on Salesforce alongside Field Service and connected-device work.

FAQ

What is Salesforce Asset Service Lifecycle Management in one line?

It is a set of Salesforce features for servicing installed assets end to end, from hierarchy and coverage to estimates, recalls, exchanges, repair and service inventory.

Should each device be an Asset or a custom object?

Asset, in almost every case. Entitlements, warranties, work orders, ASLM and Field Service already relate to it, and a custom object means rebuilding those relationships by hand.

Where should raw telemetry live?

Outside the transactional org, in a store built for time series. Salesforce should hold current state, the events that changed it and the decisions taken, not every reading.

How do warranty and entitlement differ?

A warranty term describes what is covered on a unit, such as parts, labour and expenses. An entitlement or service contract describes what the customer has bought, including support levels and dates. Most organisations need both.

Can we do this without Field Service?

Yes. Asset, warranty and entitlement modelling works in Service Cloud alone. Field Service becomes necessary once you are dispatching technicians, managing parts and scheduling maintenance visits.

What a Salesforce PDO Does, and When to Hire One

Tekunda Team — Thu, 08 Oct 2026 06:03:15 GMT

Short answer: a Salesforce PDO (Product Development Outsourcer) is a Salesforce consulting partner that builds commercial apps on the platform for software vendors, packages them, and takes them through security review onto AgentExchange, the marketplace that absorbed AppExchange in April 2026. You hire one when you have a product to ship on Salesforce, not when you are short one developer.

What is a Salesforce PDO?

A Product Development Outsourcer is a Salesforce partner whose speciality is building products on the platform rather than configuring the platform for one company. Salesforce runs PDO as a named partner track, with Master Navigator and Specialist Navigator tiers listed in its own PDO directory, so "Salesforce PDO" is a defined role, not a marketing label. ISVs (independent software vendors) hand a PDO the parts of product delivery that are specific to Salesforce: package architecture, namespace and dependency strategy, licensing, the marketplace listing, and the security review that gates all of it.

The one-line difference:

A system integrator makes Salesforce fit your business.
A PDO turns your idea into something other businesses install into theirs.

What does a Salesforce PDO actually do?

Product architecture. What belongs inside the managed package, what stays in your own service, and what has to be configurable per subscriber.
Packaging. 1GP or 2GP, namespace registration, cross-package dependencies, and a version strategy you can live with for years. If you have not settled that yet, our guide to Salesforce packaging models for ISVs lays out the trade-offs before a PDO locks them in.
Security review. Preparation, submission, and remediation when the reviewers come back with findings.
Licensing and provisioning. The License Management App, trial flows, and the listing itself.
Release engineering after launch. Patches, upgrades and pushed versions that do not break orgs you cannot see.
Support design. An ISV supports installs it does not control, which is a different discipline from supporting one org.

Only the first item resembles ordinary Salesforce delivery work. The rest is product operations, and it is where first-time ISVs lose quarters. That full scope, from first design to a listed package, is what our AppExchange app build service covers.

What changed for Salesforce PDOs and ISVs in 2026?

Three platform shifts change what a PDO has to know this year:

AppExchange became AgentExchange. On 17 April 2026 Salesforce announced AgentExchange, one marketplace that merges AppExchange, the Slack Marketplace and the Agentforce ecosystem, with more than 10,000 Salesforce and partner apps. Every listed solution still goes through security review.
Connected apps gave way to external client apps. Salesforce's developer docs state that connected app creation is restricted as of Spring '26 and recommend external client apps instead. Trailhead calls the ability to distribute external client apps with second-generation managed packages their greatest advantage, with OAuth consumer credentials kept out of the package.
The OAuth hardening deadline has passed. Partners had until 11 May 2026 to enable four controls on their apps and self-attest to them. More on that below.

When should you hire a Salesforce PDO?

Five signals, in rough order of urgency:

You have a product thesis and a first design partner, but no namespace and no packaging decision on paper. This is the cheapest moment to bring a PDO in, because nothing is locked yet.
Your app works in a sandbox and breaks as a package. Namespace prefixes, dynamic SOQL and cross-package dependencies fail in ways unpackaged code never does.
You are approaching security review for the first time. The failure mode is rarely a single rejection. It is three rejections and two lost quarters. Our walkthrough of how ISVs pass the AppExchange security review shows where those cycles usually get lost.
You are on 1GP and want to move to 2GP. Salesforce made Package Migrations generally available in Summer '25, which converts a 1GP package to 2GP and migrates installed subscribers. The question is no longer whether, but when and in what order, and which 2GP choices are permanent once you make them. External client apps only add to the case, because they are built to ship in 2GP.
You have subscribers and every release now carries risk. Once other companies depend on your version numbers, release engineering stops being optional.

Why is hiring a PDO a product decision, not a staffing one?

Staff augmentation answers a capacity question: we need two more Apex developers for six months. A PDO engagement answers a product question: we need version 1.0 listed, reviewed and installable by Q2. The second framing is harder to buy and far better to own, because almost every expensive mistake in ISV delivery is a decision, not a shortage of hands.

A namespace is registered once and stays with the package. The 1GP or 2GP choice sets your release model for years. What you put inside the package determines what you can change later without asking every subscriber for permission. None of that is solved by adding capacity to a team that has never shipped a package.

If your Salesforce work has a roadmap, subscribers and a version number, you are buying product engineering. Buy it that way.

What does Salesforce security review actually gate?

Security review is a product gate, not a code-style check. It looks at how your package handles data, secrets, sharing and access, and it comes back around as the platform's requirements tighten.

The live example is OAuth on connected apps and external client apps. Salesforce's ISVforce guide required partners to enable OAuth PKCE, refresh token rotation, a 30-day idle refresh token time-to-live and a refresh token IP allowlist, and to self-attest to them by 11 May 2026. Once attested, the controls lock and cannot be disabled, and the guide warns that non-compliance can lead to de-listing or suspension of the app's interoperation with Salesforce. If your app missed that date, it is now a remediation item, not a roadmap item, and it is the kind of obligation a PDO tracks for you.

For the review itself, our Salesforce security review checklist lists the common findings to fix in order before you submit, and our security review service takes the submission and remediation off your plate.

How do you choose a Salesforce PDO?

Ask five questions and weigh the answers heavily:

Which packages have you taken through security review, and in which industries? Regulated sectors raise the bar.
Show me a 2GP package you maintain today. Building one is not the same as versioning one across subscriber orgs.
How are you handling external client apps and the 2026 OAuth controls? A current PDO answers this without looking it up.
Who owns remediation if review comes back with findings? The answer should be them.
What happens after launch? A partner who disappears at listing leaves you the hardest part.

Tekunda answers those from delivery rather than from a brochure. We are a certified Salesforce SI, ISV and PDO, we have cleared AppExchange security review in healthcare, logistics and manufacturing, and we have shipped and maintained packages in production: the Syntilio managed packages we engineered for an eHealth ISV (2022 to 2025) on the AppExchange, and the 2GP managed package for ASSA ABLOY that carries its connected-device workload. Being an ISV and a PDO also makes us a faster integrator, because product-grade components get reused instead of rebuilt. Talk to us about your app.

FAQ

What does PDO stand for in Salesforce?

Product Development Outsourcer: a Salesforce consulting partner specialised in building, packaging and listing commercial apps for software vendors.

What is the difference between a PDO and a Salesforce implementation partner?

An implementation partner configures Salesforce for one company's own use. A PDO builds a packaged product that many companies install, which adds namespace, versioning, licensing and security review to the job.

Do I need a PDO to pass security review?

No. Plenty of ISVs pass on their own. A PDO mainly buys you fewer review cycles, because the common findings become predictable once you have been through it several times.

Is a Salesforce PDO the same as Plauti PDO?

No. Plauti Data Orchestration, also shortened to PDO, is a Salesforce product from Plauti. A Salesforce PDO is a type of consulting partner.

How early should an ISV bring in a PDO?

Before the namespace and packaging decisions are made. Those are the choices that are expensive to reverse, and they are usually made in week one.

Agentforce Partner With Proven Deployments: How to Check the Proof

Tekunda Team — Mon, 05 Oct 2026 12:00:00 GMT

An Agentforce partner with proven deployments is one that can show agents running in production for real customers, with measured outcomes, a client you can verify and a support model after go-live. Certifications and partner tiers show a firm has studied Agentforce. Production evidence shows it has shipped it. Ask for the second before you sign.

What counts as a proven Agentforce deployment?

Salesforce drew the line itself in April 2026 when it launched its Forward Deployed Engineering Partner Network: partners were chosen for a track record of delivering Agentforce, and the designation prioritises technical rigor and production outcomes over firm size or tenure. Use the same filter. A deployment is proven when it passes four tests:

It is live. Real users or customers rely on it every day. A pilot, a demo org or a hackathon build is not a deployment.
It is measured. There is a before and after number: cases deflected, handle time, resolution rate, hours saved.
It is verifiable. You can speak to the client, or the partner can walk you through it under NDA.
It is maintained. Someone owns the agent after go-live, tunes it and watches what it costs.

How do you verify an Agentforce partner's proof?

Most partner rankings sort firms by size, certifications and reviews. That says little about whether the team in front of you has taken an agent from sandbox to production. Ask these five questions instead:

Is this case study a live deployment or a scenario? Honest partners label the difference. We do: our real-estate story is marked as a scenario, not a named engagement.
Which actions does the agent take, and on which systems? Good answers name objects, flows, APIs and guardrails, not adjectives.
What happened in the first 90 days after go-live? A partner who has run agents in production can tell you what broke and how they tuned it.
Who on this team built it? Make sure the people behind the reference are the people staffed on your project.
How do you test agents before release? Look for regression tests on topics and actions, sandbox deployments and a real release pipeline, not manual clicking.

For the contract, staffing and governance side, use our buyer-side checklist for choosing a Salesforce implementation partner. It applies whether you are looking for a Salesforce Implementierungspartner in Germany or a partner in the Netherlands.

Can you help me calculate the ROI of implementing Agentforce?

Yes, and a proven partner should start there. Agentforce pricing is usage based: Flex Credits cost $500 per 100,000 credits and a standard action consumes 20 credits, about $0.10, according to Salesforce Ben's pricing guide. The ROI math is the volume of actions times the cost per action, set against the minutes of human work each action removes. Our guide to the Agentforce ROI calculator walks through the inputs and the costs most calculators leave out, such as data cleanup and integration work.

Does your Agentforce partner understand Headless 360 and MCP?

Agents rarely live inside one system. In August 2026 Salesforce expanded Headless 360, its model for letting authorised AI agents discover and use Salesforce capabilities, including a Headless 360 MCP Server in open beta that works with agents running in Agentforce, Claude, ChatGPT and other platforms. A partner with enterprise integration experience should explain when an agent calls Salesforce through MCP, when it calls your ERP or telephony platform, and how permissions stay enforced across both. If your agent must reach an ERP such as Odoo, a partner who integrates it too saves you a handoff, which is why we became an Odoo partner.

When should a partner tell you not to use Agentforce?

Proof includes saying no. Agentforce fits bounded CRM work: case triage, record updates, knowledge answers. Novel decision support across many data sources often needs a custom agent. A partner with only one answer is a vendor, not an advisor. We break the decision down in Agentforce vs custom AI agents.

What does Tekunda's production proof look like?

We are a certified Salesforce SI, ISV, PDO and Agentforce partner, and an Anthropic (Claude) partner. Here is what we can show:

20+ organisations live in production on Salesforce.
For ASSA ABLOY (FocusCura and Phoniro), weekly cases fell from 3,000 to 350, a 93% reduction, across 11,000 connected devices in three markets with no added support staff.
Agentforce agent-to-agent (A2A) orchestration running in production.
AppExchange security review cleared in healthcare, logistics and manufacturing, which matters when your agent ships as a managed package and your security review checklist has to pass for real.

See how we scope and run a first use case on our Agentforce implementation page, or start at Tekunda for the full portfolio.

FAQ

What is an Agentforce partner with proven deployments?

A Salesforce partner that can show Agentforce agents live in production for real customers, with measured outcomes and a client you can verify.

Is an Agentforce Specialist certification enough proof?

No. A certification shows individual knowledge. Ask for live deployments, metrics and references from the team you will actually work with.

How much does Agentforce cost per action?

Under the Flex Credits model a standard action uses 20 credits, about $0.10, with credits sold at $500 per 100,000.

What is the Headless 360 MCP Server?

A Salesforce MCP server, in open beta as of August 2026, that lets authorised agents in Agentforce, Claude, ChatGPT and other tools discover and invoke Salesforce capabilities.

How long does an Agentforce deployment take?

It depends on data readiness and integrations. Partners with reusable, packaged components can bring a bounded use case live in weeks rather than months.

Why Most AI Agents Fail in Production & How We Built One That Doesn’t

Tekunda Team — Sun, 04 Oct 2026 07:44:58 GMT

Short answer: AI agents usually fail in production because of the system around the model, not the model itself. The usual causes are demo-sized scope, no real integration with the systems of record, generic context, silent failures nobody can trace, no feedback loop, and no one who owns the outcome or the cost. We hit most of these building our own outbound prospecting agent. Below is how to diagnose yours, and what we changed to make ours hold up.

Why do AI agents fail in production?

The failure rate is not anecdotal. Gartner predicts that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. S&P Global Market Intelligence found that 42% of companies abandoned most of their AI initiatives in 2025, up from 17% the year before, and that organisations scrapped 46% of proofs of concept before production. MIT's NANDA research put the core problem in integration and learning, not model quality. We cover the wider picture in AI agents in 2026: what actually works and why most efforts stalled.

In our experience, those numbers break down into six failure modes:

Demo scope, production reality. The prototype ran on clean sample data and one happy path. Real records are messy, incomplete and full of edge cases.
No real integration. The agent cannot read from or write to the system of record, so its output dies in a chat window instead of changing anything.
Generic context. A clever prompt stands in for knowledge of your business. Without retrieval over your own data and outcomes, answers are plausible but wrong.
Silent failures. A wrong tool call, an empty retrieval or an invented field looks like a normal answer unless every step is traced.
No feedback loop. The agent never learns which outputs worked, so quality decays as your data and market drift.
No owner for value or cost. Nobody owns the business metric, token and API spend grows, and the project is cut at the next budget review.

How can you tell which one is breaking your agent?

Match the symptom to the cause before you change the model or the prompt:

It worked in the demo and fails on real records: scope and data. Test against a sample of real historical cases, not hand-picked ones.
Outputs look right but nobody acts on them: integration. Write results back to the CRM or ticketing system where people already work.
Answers are generic or confidently wrong: context. Ground the agent in retrieval over your own records and outcomes.
You cannot explain why it did something: observability. Trace inputs, tool calls, retrievals and outputs for every run.
It was good at launch and got worse: feedback. Feed real outcomes back into ranking and prompts on a fixed cadence.
Costs climb and nobody can say what it earns: ownership. Tie the agent to one measurable outcome, as we explain in what it takes to drive ROI from AI agents.

How did we build an outbound agent that holds up in production?

At Tekunda we wanted more than a meeting-room demo: an agent that automates outbound prospecting across LinkedIn and Salesforce, reasons over real context and books calls. Each step below exists because one of the failure modes above bit us first.

1. Start from one bounded job

The agent owns a single workflow: from a LinkedIn lead list to a booked call. A search result or Sales Navigator list goes into Linked Helper, which automates connection invites within LinkedIn's weekly invitation limits, thank-you follow-ups and the sync into Salesforce. Once a new connection lands in the CRM, the agent takes over.

2. Ground it in your own outcomes

The agent reasons over past lead data, including conversion history, success criteria and segment traits, as retrieval context. We tested both vector stores and PostgreSQL-based retrieval and chose on performance and cost, with chunking and retrieval tuned for lead qualification rather than generic search.

3. Orchestrate with real tooling, not one giant prompt

Logic runs in Langflow, backed by custom Python flows and our internal MCP servers that handle API calls, enrichment and prompt execution. The flow is stateless and split into small micro-flows we reuse across campaigns. When one agent becomes several, handoffs become the next failure point, which is why we wrote up what makes agent-to-agent handoffs work in production.

4. Enrich, score and explain every decision

Each lead is enriched with a verified work email using Findymail.
The agent pulls signals such as job changes, funding and tech stack from public sources using OpenAI search or Perplexity.
It scores each lead out of 100 by similarity to past wins and writes an explanation for every score, so a human can audit the reasoning.
Only leads scoring above 50 get outreach.

5. Write back to the system of record

For qualifying leads, the agent drafts a personalised email from company information, role signals and recent activity, with a call-to-action modelled on what worked in earlier wins. Every email is pushed back into Salesforce, so sales sees the same record the agent acted on.

6. Observe everything and iterate weekly

We trace every agent output in Langfuse and internal dashboards, with structured error handling, prompt diffing and outcome analysis built into the flow. Conversion signals feed back into the ranking and prompt layers, and each week we refine prompts, retrain embeddings and tune scoring. That loop is the difference between an agent that decays and one that improves.

The result is no manual handoff from invite to booked call. LinkedIn caps the top of the funnel, but enrichment, scoring and email generation behind it scale with the pipeline.

What should be in place before an agent goes live?

One measurable outcome and a named owner for it.
Read and write access to the system of record, with the least privilege the job needs.
An evaluation set of real historical cases, run before every prompt or model change.
Tracing for every step: inputs, tool calls, retrievals and outputs.
A human checkpoint wherever a mistake is expensive, such as a score threshold or an approval step.
A feedback loop on a fixed cadence, with real outcomes as input.
A cost budget per outcome, reviewed alongside the business metric.

If your agent lives inside Salesforce, decide early whether to configure or build: our guide to Agentforce vs custom AI agents walks through that call. And if you want an agent like this built around your own workflow, see how we build production AI agents or talk to our team.

FAQ

Why do my AI agents work in testing but fail in production?

Testing usually runs on clean data and a single happy path. Production adds messy records, real integrations and edge cases, and without tracing those failures stay silent.

How many AI agent projects fail?

Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027, and S&P Global found 42% of companies abandoned most of their AI initiatives in 2025.

How do you monitor an AI agent in production?

Trace every run, including tool calls and retrievals, and track prompt changes against outcomes. Tools like Langfuse plus internal dashboards make agent decisions debuggable.

Should we build an AI agent in-house or work with a partner?

MIT's NANDA research reported that solutions bought from specialised vendors succeed far more often than internal builds. Build in-house when the workflow is core and you can staff observability and iteration.

Enterprise MCP Integration: Connecting AI Agents to Salesforce Safely

Tekunda Team — Sat, 03 Oct 2026 12:00:00 GMT

Enterprise MCP integration means exposing your business systems to AI agents through the Model Context Protocol, an open standard, instead of building one custom connector per agent and per tool. Done well, every agent call runs under a real user's identity and permissions, so the security model you already trust carries over. Done badly, it is a new, unaudited back door into your CRM.

What is enterprise MCP integration?

MCP is an open protocol that lets an AI client (Claude, ChatGPT, Agentforce, an IDE) discover and call tools published by an MCP server. Anthropic introduced it in November 2024, and in December 2025 it was donated to the Agentic AI Foundation under the Linux Foundation, so no single vendor controls it.

The word "enterprise" adds three requirements that quick demos skip: per-user authentication, least-privilege authorization and an audit trail for every tool call.

Why are enterprises standardizing on MCP now?

Because the major platforms shipped it. OpenAI adopted MCP in March 2025 and Google DeepMind followed in April 2025. On the Salesforce side, hosted MCP servers reached general availability on April 29, 2026 for Enterprise Edition and above, with no separate connector fee. On August 19, 2026 Salesforce expanded Headless 360 with a Headless 360 MCP Server in open beta and a generally available Data 360 MCP Server.

The practical effect: integration work shifts from writing connectors to governing what agents may do. It is the same discipline as classic Salesforce integration architecture, applied to a new kind of caller.

What is the Salesforce Headless 360 MCP server?

The Headless 360 MCP Server gives an agent four tools instead of thousands of endpoints:

Discover - semantic search over a library of skills.
Describe - returns the API contract and ordered steps for one skill.
Dispatch - executes the chosen skill.
Dispatch Read Only - runs read-only operations.

The beta launched in July 2026 with roughly 100 skills, covering user management, Apex triggers, platform events, Change Data Capture and Named Credentials. Salesforce says agents inherit the identity, permissions and business logic already configured in the org. We cover rollout and sizing in our Headless 360 adoption guide.

How is MCP different from a direct API integration?

Caller: an API integration is a fixed program; an MCP caller is an agent choosing tools at runtime.
Contract: APIs are coded against ahead of time; MCP tools are discovered and described on the fly.
Identity: API integrations often run as one integration user; a well-built MCP setup runs per user with OAuth.
Risk: an API does exactly what it was coded to do; an agent can chain tools in ways nobody tested.

MCP does not replace your middleware. Order sync between Salesforce and an ERP still belongs in deterministic flows, as in our Salesforce and SAP integration patterns. MCP is the layer for agent-driven, human-supervised actions.

What belongs on an enterprise MCP security checklist?

Per-user OAuth, never a shared token. Salesforce hosted servers use OAuth 2.0 with PKCE through an External Client App, so CRUD, field-level security and sharing rules apply to every call.
Audience-bound tokens. The MCP authorization specification requires servers to accept only tokens issued for them and forbids passing other tokens through.
Read first. Start with a read-only server or tool, then grant write access per use case.
Human approval on writes. Require approval before any tool call that changes data.
Vet every third-party server. Prefer vendor-published servers and review community ones like code you are about to deploy.
Log every tool call with user, input and outcome.

For Salesforce teams the upshot is simple: your Salesforce security checklist (profiles, permission set groups, sharing) is now your agent security checklist too. Over-permissioned users become over-permissioned agents.

Does RingCentral have an MCP server?

Yes, in labs form. RingCentral staff point users to servers for RingEX Phone, Chat and Admin documented at mcp.labs.ringcentral.com, according to the RingCentral community. (If you searched for ringcentral.vom, the domain is ringcentral.com.) Community-built RingCentral servers also exist, and their security quality varies, which is exactly why item 5 on the checklist exists.

How do you calculate the ROI of Agentforce and MCP integration?

Salesforce's Agentforce calculator estimates Flex Credits and list price from your industry, company size, seats and action volumes, for the first year, and Salesforce labels the results illustrative only. To build a business case you can defend:

Pick one workflow and count how often it runs per month.
Measure today's handling time, including swivel-chair work across systems.
Estimate the share of runs an agent can complete with human approval.
Subtract consumption costs and the integration and governance build.

Cross-system workflows usually carry the most value, because that is where people copy data between tabs. See running CRM actions from one agentic hub for a worked example.

How do you choose a Salesforce implementation partner for MCP work?

They start with your permission model, not the demo.
They can explain which flows stay in middleware and which move to MCP.
They scope a read-only pilot with a measurable outcome before granting write access.
They hand over logging, runbooks and ownership, not just a working agent.

That is how we run Headless MCP projects at Tekunda: one governed workflow first, then scale. You can learn more about our team on tekunda.com.

FAQ

Does the Salesforce hosted MCP server cost extra?

There is no separate connector fee, but it requires Enterprise Edition or above. Agentforce usage is metered separately, which is what the Agentforce calculator estimates.

Is the Headless 360 MCP server generally available?

As of August 2026 it is in open beta. The Data 360 MCP Server is generally available.

Can an MCP agent bypass Salesforce permissions?

Not on Salesforce's hosted servers. Each user signs in with OAuth, and object permissions, field-level security and sharing rules apply to every call.

Should MCP replace our integration middleware?

No. Keep high-volume, deterministic syncs in middleware and use MCP for agent-driven actions that benefit from human oversight.

Why and How to Start a Career in the Salesforce; Skills and Resources

Tekunda Team — Wed, 23 Sep 2026 20:18:20 GMT

Looking to skyrocket your career in the tech industry? Look no further than the Salesforce ecosystem! With a growing demand for Salesforce professionals, there has never been a better time to jumpstart your career in this dynamic and fast-paced field.

But where do you start? Fear not, as we've got you covered with our comprehensive guide on why and how to start a career in the Salesforce ecosystem. From must-have skills to top certifications and resources, this blog post has everything you need to know to kickstart your career in Salesforce.

Whether you're a recent graduate or looking to switch careers, this post will equip you with the knowledge and tools to take your career to new heights. Don't miss out on the opportunity to join one of the most exciting and lucrative industries in tech - read on to learn more!

Why should you consider a career in the Salesforce ecosystem?

Work with a world-dominating technology: Salesforce is the world’s leading CRM platform posting an average year-on-year growth of 25% for the past four years and has ambitious plans to double its growth over the next few years.
Enjoy numerous job prospects: Salesforce is used by over 150,000 firms worldwide, ranging from small enterprises to Fortune 500 corporations, like Tekunda, providing enough chances for future Salesforce developers like yourself.
Participate in an exciting, innovative environment that is always changing, and have the chance to work with cutting-edge technology in a dynamic and fast-paced industry.
You become a member of an inclusive community of developers, administrators, and users who are always happy to assist and support one another, providing you with access to a plethora of information, resources, and training opportunities to help you grow and improve your talents.
Multiple routes into the ecosystem to become a Salesforce developer. Whether you are a recent graduate or an experienced developer, there are many opportunities available to help you get started in this exciting and dynamic field.

Essential Skills for a Salesforce Professional

To thrive in the Salesforce ecosystem, it's crucial to develop a mix of technical and non-technical skills. Some of the most sought-after skills include:

Salesforce Administration: Mastery of core CRM functionalities, such as user management, security settings, and data management.
Salesforce Development: Proficiency in Apex, Visualforce, and Lightning Web Components to create custom solutions and integrations.
Salesforce Configuration: Understanding of declarative tools, such as Process Builder, Flow, and Workflow Rules, to automate processes without coding.
Data Analysis and Reporting: Ability to extract insights from data using Salesforce reporting tools and dashboards.
Project Management: Expertise in managing Salesforce implementation projects, following best practices, and ensuring timely delivery.
Communication and Collaboration: Strong interpersonal skills to effectively collaborate with cross-functional teams and stakeholders.

Common job roles in Salesforce development

Salesforce Administrator is responsible for configuring and managing the Salesforce platform. They ensure that the system is running smoothly, and they are responsible for managing user accounts, data security, and customisations.
Salesforce Developer is responsible for creating custom solutions using programming languages like Apex and Visualforce. They're also responsible for integrating Salesforce with other systems and platforms, such as ERP systems and marketing automation systems.
Salesforce Consultant is responsible for helping businesses implement Salesforce solutions. They work with clients to understand their needs and requirements and provide guidance on how to best use the platform to meet their business goals.
Salesforce Architect is responsible for designing and overseeing the implementation of complex Salesforce solutions. They have a deep understanding of the Salesforce platform and its capabilities and work closely with clients and developers to ensure that solutions are designed and implemented correctly.

How to kick off my Salesforce Development career?

Technical Skills

Salesforce Development requires a strong understanding of the Salesforce platform, including its architecture, data model, security features, and customisation options, as well as programming languages like Apex and Visualforce.

Apex is the programming language used to write custom code for the Salesforce platform. It's essential that you have an in depth understanding of Apex and the best practices for writing efficient and scalable code.
Visualforce is a markup language used on the Salesforce platform to construct bespoke user interfaces. You must be well-versed on Visualforce and its capabilities, as well as its best practices to build successful user interfaces.
Lightning Web Components (LWC) is a programming model and framework for building responsive web interfaces on the Salesforce platform. You should develop a strong understanding of LWC and its capabilities, as well as best practices for building efficient and effective web interfaces.
Integration: you must be well-versed in integration methods and technologies such as REST, SOAP, and OAuth to be able to integrate Salesforce with other systems and platforms, such as ERP systems, marketing automation systems, and other third-party applications

Gain Experience

To build a successful career, you need practical experience working on projects. You can gain this experience by working on personal projects, contributing to open-source projects, or working on small projects for willing clients.

Get Certified

Salesforce offers a range of certifications for developers, including the Salesforce Certified Platform Developer I and II certifications.

Network

Building a strong network of contacts in the Salesforce community can help you to find job opportunities, connect with other developers, and stay up-to-date with the latest trends and best practices in the industry.

Develop Your Soft Skills

It's crucial that you have excellent communication skills, as well as the ability to work with a variety of stakeholders, including business users, project managers, and other developers. So work on sharpening those communication skills to prepare yourself for a successful career.

Free Resources to Learn Salesforce Development

Trailhead: Salesforce's free learning platform offers a variety of modules and trails on Salesforce development. You can learn at your own pace and earn badges and certifications as you complete modules.
Developer Community: The Salesforce Developer Community is a fantastic environment to meet other developers, ask questions, and learn from industry leaders.
YouTube: Some popular channels include Salesforce Developers, Admin Hero, SFDC Monkey, and many more YouTube channels that offer tutorials and walkthroughs on Salesforce development.
Blogs: Including the official Salesforce Developer Blog, which offers insights and best practices on Salesforce development.
Open-Source Projects: Contributing to open-source projects can be a great way to gain practical experience and build your portfolio. The Salesforce Open-Source Community offers a variety of projects that you can contribute to.
Meetups: Attending local meetups and user groups can be a great way to network with other developers and learn about the latest trends and best practices in the industry.

Salesforce Certifications to Elevate Your Career

Salesforce offers a range of certifications catering to various roles, such as administrators, developers, architects, consultants, and marketers. Some popular certifications include:

Salesforce Certified Administrator: Validates your knowledge of Salesforce configuration, management, and best practices.
Salesforce Certified Platform Developer I: Demonstrates your ability to build custom applications using Apex and Visualforce.
Salesforce Certified Platform App Builder: Showcases your proficiency in designing, building, and implementing custom applications using declarative tools.
Salesforce Certified Sales Cloud Consultant: Validates your expertise in designing and implementing Sales Cloud solutions that meet customer requirements.
Salesforce Certified Service Cloud Consultant: Demonstrates your ability to design and deploy Service Cloud solutions to enhance customer support.

FAQ

Do you need a degree to start a Salesforce career?

No. Many admins and developers move in from support, sales or operations. Trailhead badges, one certification and a few real projects carry more weight than a degree.

Which Salesforce certification should you start with?

Most people start with Salesforce Certified Administrator, then add Platform App Builder or Platform Developer I. Choose the one that matches the role you want.

Should you learn admin skills or Apex first?

Learn the admin side first. Once the data model, security and declarative automation make sense, Apex and Lightning Web Components are much easier to pick up.

How do you get experience without a Salesforce job?

Build in a free Developer Edition org, contribute to open-source Salesforce projects, and take on small projects for community groups. A portfolio you can demo beats a line on a CV.

Is Salesforce still a good career choice?

Yes. The ecosystem needs admins, developers, consultants and architects, so there are several ways in and clear routes to move between them later.

Conclusion

Embarking on a career in the Salesforce ecosystem can be both interesting and lucrative. Because of the platform's popularity and the growing need for competent developers, there are several opportunities for anyone willing to put in the effort to get the necessary skills and expertise. Building a successful career requires a combination of technical expertise, professional certifications, and real-world experience outlined in this article. You can get started by taking advantage of the free resources available, such as Trailhead, the Developer Community, and open-source projects. If you want to join a creative team that is developing breakthrough Salesforce products, visit our careers page and apply for one of our open roles.

Case Study: Transforming Customer Support with Salesforce 🚀

Tekunda Team — Wed, 23 Sep 2026 20:18:20 GMT

Challenge

Our client, a top player in the retail industry, was grappling with the complexities of managing customer support across multiple channels. They needed a robust solution to streamline communications, improve case handling, and integrate various systems for a seamless customer experience.

Solution

Partnering with Tekunda, we helped the retailer leverage Salesforce Service Cloud to transform their customer support operations. Here’s how we made it happen:

1. Enhanced Communication Channels:

Implemented phone, email, chatbot, WhatsApp, FB Messenger, and web forms for broader reach and convenience.

2. Improved Internal Collaboration:

Chatter: Enabled Chatter for real-time collaboration within the support team.
Inter-Org Communication: Established seamless data exchange with their international branches using Salesforce-to-Salesforce integration.

3. Streamlined Case Handling:

Developed a smart feature to guide agents through a standardised support flow with dynamic questions and answers.
RingCentral Integration: Integrated RingCentral for efficient call handling directly within Salesforce.
Knowledge Base: Provided knowledge articles based on case reasons to empower agents with quick, accurate information.
Automation: Automated customer email notifications, case owner changes, and post-case surveys to enhance efficiency and customer satisfaction.
Omni-Channel Routing: Deployed Omni-Channel to intelligently route cases to the most suitable agents.
SLA Dashboard: Implemented a dashboard for real-time monitoring of service level agreements, ensuring timely case resolutions.

4. Robust Collaboration Features:

Displayed case history, order history, and track & trace functionalities.
Displayed all relevant information to streamline case handling and enhance agent productivity.

Results:

Increased Efficiency: Achieved a 30% reduction in case resolution time.
Higher Customer Satisfaction: Customer satisfaction scores improved by a staggering 35%.

FAQ

Can Service Cloud handle WhatsApp and Messenger?

Yes. Phone, email, chat, web forms and messaging channels such as WhatsApp and Facebook Messenger all land in the same console, so agents work one queue instead of five inboxes.

What does Omni-Channel routing do?

It assigns each case to the agent best placed to solve it, using skills, availability and current workload, instead of leaving work in a shared queue for whoever grabs it first.

How can two Salesforce orgs share case data?

Salesforce-to-Salesforce lets separate orgs publish and subscribe to records, so international branches exchange cases and accounts without building a custom integration.

How do you monitor SLAs in Salesforce?

Entitlements and milestones put a clock on each case, and an SLA dashboard shows which cases are close to breaching so supervisors can step in before they do.

Conclusion

By leveraging Salesforce Service Cloud, Tekunda transformed the retailer’s customer support operations, delivering a superior customer experience and driving operational excellence.

Ready to elevate your customer support? Let Tekunda guide you through the transformation with Salesforce Service Cloud!

#Salesforce #CustomerSupport #CaseStudy #Innovation #Retail #CustomerExperience #Tekunda #ServiceCloud #DigitalTransformation

Case Study: Syntilio Platform on the AppExchange (Salesforce PDO)

Tekunda Team — Wed, 23 Sep 2026 20:18:20 GMT

Introduction

Tekunda helped Syntilio realise its vision of reducing the pressure on healthcare by facilitating personal and efficient unplanned care using insight-driven triage. We delivered Syntilio as a PDO-grade managed package on top of Salesforce Service Cloud, giving every stakeholder a single, secure, scalable platform.

For every care request, clinicians gain a 360° view of each client - including medical history, social context, and telemetry - tightened to urgent decision-making. The same platform activates formal and informal care networks, so care teams can deploy the right resources, at the right time, across an entire region.

Why Chose Tekunda

Syntilio asked for an enterprise-grade platform that could orchestrate unplanned care, unify disparate partner systems, and respect strict health regulations. Tekunda responded with a managed-package architecture that blends modularity, multi-tenant upgrade paths, and uncompromising governance. Queueable Apex jobs with guarded retries and chained follow-on scheduling keep the data fabric fresh, even while handling millions of telemetry updates or care-plan revisions. Each capability is surfaced through LWC, Experience Cloud, or omni-channel flows, so the front-line teams feel the impact immediately.

Because Tekunda is a PDO, we owned the delivery lifecycle on the vendor's behalf: packaging strategy, security review preparation, licensing setup and AppExchange release operations. Clients trust us to keep their product roadmap in motion while staying compliant with local rules.

Let Tekunda Build Your Salesforce Product

Need a Salesforce-managed package with complex integrations, high scalability, IoT, LWCs, etc..? Tekunda is your Salesforce-native partner, contact us and map your managed package in a PDO-focused session.

Talk to Tekunda

Solution Breakdown

Insight-Driven Triage

Care teams start every engagement with a holistic, real-time dossier. Dynamic protocols, telemetry readings, social determinants, and medical notes flow into a single Lightning workspace. Omni-Channel routing flags the right specialist instantly, while RingCentral telephony and secure messaging initiate support in seconds.

Appropriate And Fast Follow-Up

The platform connects formal and informal care networks. Families, volunteers, community nurses, and specialists share one canvas - driving faster follow-up with full accountability. The system nudges human interventions only when necessary, reducing healthcare pressure without compromising outcomes.

A No-Code Triage Toolkit That Ships In Hours

Clinical leaders customise triage without waiting on deployments. Tekunda embedded a SurveyJS-powered React builder directly inside Salesforce via custom LWCs. Subject-matter experts drag and drop new assessments, flows, and reusable content, then publish instantly to the React triage app. Guardrails ensure no duplicate questions, no missing validations, and a consistent experience across teams. One regional partner launched a specialised fall-risk protocol in a single afternoon - something that previously took multiple sprints.

DataHub In Action

Interoperability is the backbone. When a new client is qualified in Syntilio, the DataHub automatically synchronises records with ECDs, tele-monitoring platforms, and scheduling apps - and vice versa. DataHub understands destinations dynamically: we compose headers on the fly, fan out to multiple external APIs, and apply recursive post-processing so every downstream system receives exactly the payload it expects.

Each callout is audited end-to-end. Destinations, payloads, responses, and status codes are persisted in Salesforce for operational dashboards. When something goes wrong, care teams investigate with full traceability and Tekunda’s support engineers already have the context they need. This “always-on audit trail” is why partners trust Tekunda to keep their data lakes, IoT brokers, and systems in check.

Built for scale and IoT, powered by stateless Azure Functions, DataHub processes millions of events with low latency and zero infrastructure overhead. GitHub Actions orchestrate every "hot swapped" API deployment, so releases move from feature branch to production with automated tests, security scans, and compliance gates.

CareHub

The CareHub managed package anchors remote monitoring in Salesforce Service Cloud:

Flows orchestrate complex IoT device data and automate patient workflows.
Custom LWCs provide omni/smart search, safety badges, and contextual insights.
Apex services integrate on-demand with ECDs/EPDs, scheduling engines, and partner networks.
The React triage app streamlines protocol execution for front-line workers.
Omni-Channel routing pushes tasks, alerts, and escalations to the right responder in real time.
RingCentral telephony integration enables direct provider-client communication.
Experience Cloud portals empower patients, families, and partners with secure self-service.
Salesforce Scheduler coordinates appointments across clinics and home-care teams.

Regional cooperation, asset tracking, and device monitoring (battery status, connectivity, fault detection) all live in one platform. Managed package modularisation - core, device, triage, portal - keeps upgrades predictable and extensible.

VideoHub

VideoHub delivers Telehealth purpose-built for acute and planned care. Developed with WebRTC, React Native, and LWC, it plugs into CareHub so clinicians can launch secure calls directly from the case dossier. Encrypted media streams, consent-aware logging, and intuitive UI elevate patient satisfaction while maintaining strict confidentiality.

Reliability & Governance You Can Trust

Tekunda’s architecture prioritises compliance and resilience:

Standards-compliant interoperability: FHIR/HL7 APIs with optional SMART on FHIR for clinical data exchange.
Event-driven sync: Salesforce Platform Events and server-less handlers (Azure Functions, IoT Hub) avoid polling.
Resilience patterns: Retries, circuit breakers, and DLQs ensure no data loss - ever.
Security: Encryption, OAuth 2.0/JWT handshakes, granular sharing, and event monitoring.
Tenant-aware packaging: Licensing, isolation, and safe upgrade paths baked into every module.
Metadata-driven configuration: Routing rules, questionnaires, and Experience pages are editable without code.
Global readiness: Extensive localisation (cases, clinical objects, portals) supports multi-country rollouts from day one.
Observability: Unified dashboards surface logs, callouts, and telemetry so teams act before issues escalate.

Tekunda’s Delivery Playbook

Our DevOps foundation mirrors what regulated industries expect. Every Salesforce change runs through Serpent pipelines: scratch-org spins, static code analysis, Apex/LWC tests, UI regression suites, and packaging checks happen automatically. Azure DataHub services use GitHub Actions for CI/CD with automated contract tests and security scanning. When Tekunda presses deploy, stakeholders already have the evidence they need to sign off.

We also operate a dedicated PDO success squad, architects, release engineers, and support specialists, who coach client teams on roadmap planning, differentiation, and AppExchange growth. The result is a predictable cadence of innovation that keeps Syntilio and its partners ahead of the curve.

Less Administration, More Impact

Every triage and follow-up step is automatically recorded. Case notes, telemetry, scheduling, and volunteer coordination sync in the background, so teams spend less time on manual updates and more time with patients. Managers gain real-time insights into caseloads, outcomes, and bottlenecks.

Conclusion: Elevate Your Salesforce Product

Syntilio’s success is a blueprint for any organisation building enterprise-grade Salesforce solutions. If you need a partner who understands managed packaging, compliance, interoperability, and go-to-market equally well, Tekunda is ready to help.

FAQ

What does a Salesforce PDO do?

A PDO builds the product for a software vendor and owns packaging, security review preparation, licensing and AppExchange operations. The vendor keeps ownership of the product itself.

Why build a managed package instead of org work?

A managed package gives every customer the same versioned code with a controlled upgrade path. Custom work inside each org has to be rebuilt and re-tested tenant by tenant.

How do you keep a healthcare package compliant?

Design for it from the start: standards-based interoperability with FHIR and HL7, encryption, OAuth handshakes, granular sharing and event monitoring. Compliance bolted on late is what delays a release.

What slows down AppExchange security review?

Findings that could have been caught earlier: insecure sharing, unescaped output, weak secret handling. Preparing the package during development rather than after it keeps the review off the critical path.

Get the Best out of your Salesforce

Tekunda architects and implements Service Cloud, Sales Cloud, Health Cloud, Scheduler, Experience Cloud, IoT, and integrations. Let’s map how Serpent-powered releases, GitHub Actions, and managed-package engineering can accelerate your roadmap.

Book a Discovery Session

How Salesforce Service Cloud is Revolutionising Customer Support

Tekunda Team — Wed, 23 Sep 2026 20:18:20 GMT

Customer Relationship Management (CRM) systems have come a long way over the past few decades. What started as basic tools to manage customer data has evolved into powerful platforms that not only store information but also help businesses engage with their customers more effectively. Salesforce Service Cloud is at the forefront of this evolution, revolutionising the way companies handle customer support.

The Changing Landscape of Customer Support

Customer expectations are higher than ever. In today’s fast-paced digital world, people expect quick, personalised, and efficient service. They don’t want to wait days for a response or be passed from one agent to another without getting their issue resolved. This shift in expectations has pushed companies to rethink how they approach customer support, and CRM systems like Salesforce Service Cloud are stepping up to meet these demands.

What Makes Salesforce Service Cloud Different?

Salesforce Service Cloud is more than just a tool to manage customer inquiries; it’s a comprehensive platform that integrates various aspects of customer service into one cohesive system. Here are some key features that set it apart:

1. Omni-Channel Support

• What It Does: Salesforce Service Cloud offers omni-channel support, allowing businesses to manage customer interactions across multiple channels like phone, email, live chat, social media, and more - all from a single platform.

• Example: Imagine a customer starts a conversation on social media, continues it via email, and then calls for further assistance. With Salesforce Service Cloud, the support agent handling the call can see the entire history of that customer’s interactions, ensuring a seamless experience.

2. AI-Powered Assistance

• What It Does: Salesforce Service Cloud leverages artificial intelligence through its Einstein AI feature to provide smart suggestions, predict customer needs, and automate routine tasks.

• Example: Suppose a customer contacts support about a billing issue. Einstein AI can automatically suggest relevant knowledge base articles or pre-written responses, speeding up resolution time. It can also predict what the customer might ask next, allowing agents to proactively address their concerns.

3. Customer Portal Capabilities

• What It Does: Salesforce Service Cloud empowers customers to solve their issues independently through customer portals and communities. Customers can access a knowledge base, FAQs, and community forums, reducing the load on support agents.

• Example: A customer needing help with a product setup can access a detailed guide in the customer portal without waiting for an agent. If they have further questions, they can post in a community forum where other customers or support staff can provide answers.

4. Customisation and Integration

• What It Does: Salesforce Service Cloud is highly customizable, allowing businesses to tailor it to their specific needs. It also integrates seamlessly with other systems, including marketing, sales, and third-party applications.

• Example: A retail company can integrate Salesforce Service Cloud with its inventory management system, enabling support agents to check product availability, process returns, or issue refunds directly from the CRM.

Real-World Impact: Use Cases

Let’s look at a couple of scenarios where Salesforce Service Cloud has made a significant difference for businesses:

Use Case 1: Enhancing Customer Experience for a Global Retailer

A global retail company was struggling with fragmented customer support across different regions. Each region used different tools and processes, leading to inconsistent service and frustrated customers.

Solution: By implementing Salesforce Service Cloud, the company centralised its customer support operations. Now, all regions use the same platform, ensuring consistent service. Omni-channel support allows customers to reach out through their preferred channels, while the AI-powered suggestions help agents resolve issues faster. The result? A 40% reduction in response times and a significant boost in customer satisfaction.

Use Case 2: Streamlining Support for a Tech Company

A tech company offering software solutions was dealing with an overwhelming number of support tickets, many of which were repetitive inquiries. Their agents were bogged down by routine tasks, leaving them with little time to handle complex issues.

Solution: Salesforce Service Cloud’s customer portal allowed customers to find answers to common questions on their own, reducing the number of incoming tickets. Meanwhile, Einstein AI automated responses to frequently asked questions, freeing up agents to focus on more challenging issues. This led to a 50% reduction in ticket volume and improved overall support efficiency.

The Future: What’s Next for Salesforce Service Cloud?

As technology continues to evolve, so too will Salesforce Service Cloud. Here are a few trends and developments that we can expect to see:

1. Deeper AI Integration

• AI will play an even bigger role in customer support, with predictive analytics becoming more sophisticated. This means anticipating customer needs before they even contact support, leading to a more proactive service approach.

2. Enhanced Mobile Support

• With more customers using mobile devices, Salesforce is likely to further enhance its mobile support capabilities, making it easier for customers to access help on the go.

3. Increased Focus on Personalisation

• Personalisation will be taken to the next level, with CRM systems like Salesforce Service Cloud offering even more tailored experiences based on customer data, preferences, and behavior.

4. Greater Emphasis on Data Security

• As data privacy concerns continue to grow, Salesforce will likely introduce more robust security features to protect customer information and ensure compliance with global regulations.

Conclusion: Why Salesforce Service Cloud is a Game-Changer

Salesforce Service Cloud is not just keeping up with the changing landscape of customer support; it’s leading the charge. By offering a platform that combines omni-channel support, AI-powered assistance, customer portals, and deep customisation, it empowers businesses to deliver exceptional customer service. Whether you’re a small business or a global enterprise, Salesforce Service Cloud can help you meet - and exceed - your customers’ expectations.

If you’re ready to transform your customer support, now is the time to explore what Salesforce Service Cloud can do for you. At Tekunda, we specialize in helping businesses unlock the full potential of Salesforce solutions. Contact us today to learn how we can help you create a future-proof customer support system that keeps your customers happy and your business thriving.

Inside Web Summit Lisbon 2025: What It's Really Like

Tekunda Team — Wed, 23 Sep 2026 20:18:20 GMT

Web Summit Lisbon 2025 in Portugal was simply “huge.” Not in the overwhelming sense, but in how everything was built , the scale, the energy, the execution. I’ve seen it firsthand, and everyone around me was simply amazed.

Picture this: a spacious arena with more than 70,000 people, thousands of startups, a sea of investors, and enough coffee to keep you talking for six days straight. But the real value wasn’t the size. It was the crowd & the pace, creating an exceptional business speed dating experience with inspiring people who are actually in the mood to talk, listen, and connect.

For everyone who couldn’t be there this year. this is both a recap of my experience and a practical guide for anyone planning to visit one of the leading tech conferences in Europe.

Networking at Web Summit Lisbon: Everyone Talks to Everyone.

What surprised me most is how easy it is to speak to people. You talk to someone in a queue or at a coffee stand, and suddenly they turn out to be exactly the type of company that needs your product or services.
The market is competitive, but in a good way. People show up ready to engage. You don’t need icebreakers; the atmosphere does the work.

The App, WhatsApp, and Random Encounters All Have a Purpose

The Web Summit Lisbon networking app helps with fast replies, scanning badges, planning talks, and finding people you’d never notice otherwise.The WhatsApp groups are nonstop invitations, event links, meetups, and intros.

But the best connections came from random encounters: standing in a queue, sitting on the floor, waiting for a stage changeover, grabbing a drink. Those moments created better leads and more honest conversations than anything formal.

Night Summit Matters More Than You Think

The Night Summit events in Lisbon’s tech ecosystem were all worth attending. It’s less formal, people open up faster, and you see the same faces again and again, which helps real relationships form.
If you’re worn out, just go anyway; these evenings were the ones that had the loudest laughter and most meaningful interactions of the whole week.

Mistakes Made (So You Don’t Repeat Them)

A few things I learned the hard way:
• While we reached out to people before the event and followed up each evening, which helped a lot. But the better approach is to start weeks earlier: connect in advance, schedule meetups, and warm up key conversations long before you land in Lisbon.
• Attended too many talks at the start. It’s better to stay on the floor and speak to people.
• Not taking enough photos or videos due to always being in valuable conversations. Get your content early, before things get fully engaged, your marketing team will thank you for not coming back empty-handed.
• If a conversation isn’t aligned with that you are looking for, it is okay to take their LinkedIn and move on. It’s normal; everyone gets it, and proudly, nobody is offended.

Your Pitch Improves Every Day

Didn’t stick to one script. I adapted the pitch depending on who I was speaking to. By day three it sounded sharper.
By day five, I could explain our value in a few seconds without thinking. When you say it so many times, it becomes second nature.

Logistics and Small Things That Actually Matter

Usually you’re just walking. The Lisbon venue feels big but easy to follow. The badge stays on everyone, even outside the event, so the city becomes part of the summit.
A few practical notes from my week:
• Wear comfy shoes. You’ll walk more than you expect, and your brain needs to focus on gain, not pain.
• Night Summit events fill fast on Luma. Register days before.
• Bring a universal adaptor. We got a monitor for our booth, and thesocket didn’t match, so the adaptor saved us.
• If you plan to give away merch, prepare it early. We were too busy talking to actually hand things out.

Lead Tracking Is Simple

The badge QR code is your best friend. Scan it, add notes, and export everything everyday. The follow-up becomes easy.
All you need in the moment is to capture interest. The real conversation can happen later, either on a quick online call or in person once the event is over.

Who Should Go

Web Summit is right for anyone who wants to:
• Enter a new market,
• Expand their network fast,
• Find early clients or partners,
• Land an investment, or pressure-test their story with people who don’t know them.

If you show up with a clear goal, stay flexible, and talk to people everywhere, even the random ones, the event pays off.

Get ready for Web Summit 2026
I’ve already bought my ticket. And if you ever want help preparing for your Web Summit run, feel free to reach out.

Salesforce Security Review Scanner Requirements in 2026

Tekunda Team — Tue, 22 Sep 2026 12:00:00 GMT

Salesforce changed which scans the security review requires: Code Analyzer moved to version 5, and Salesforce stopped running the dynamic scan for you when Chimera was decommissioned. Here is what you must run in 2026, how the pieces fit, and how to document the results so the review clears on the first submission. For the full pre-submission controls, see our Salesforce security review checklist.

Which scans are required in 2026?

Two automated scans are mandatory, and skipping either is the fastest way to fail:

Salesforce Code Analyzer is now generally available at version 5, free, and built into the Salesforce CLI. It runs multiple engines and ships with more than 500 rules across Apex, Lightning, Visualforce, and Flow. Version 4 was retired in August 2025, so make sure your pipeline calls v5.
The Source Code Scanner (Checkmarx) runs through the partner portal and is required in addition to Code Analyzer.

Salesforce also gives you a requirements checklist builder that tailors the scan list to the technologies your package actually uses, so you are not proving controls you never ship.

Who runs the dynamic scan now that Chimera is gone?

You do. If your package calls a service you operate, that service is in scope: run your own dynamic (DAST) scan with an accepted tool such as OWASP ZAP or Burp Suite and attach the report. Salesforce stopped running that scan for you when Chimera was decommissioned in June 2025, so see running your own dynamic scans after Chimera and remove Chimera from your runbook if it is still there.

How do you document the scanner results?

The scanners are the easy part. Packages fail on the human steps around them. The two we see most often:

Undocumented false positives. A scanner flags a line you have already mitigated, you leave it unexplained, and the reviewer treats an unanswered finding as an open risk.

The fix is a short remediation note for every flagged item you did not change, explaining why it is safe. When a scan comes back noisy, our companion piece on what to fix, in order sets the priority. The second trap is treating remediation as a single pass. You scan, fix, and re-scan until the report is clean, then submit the clean report, not the first one. Budget for that loop; a rushed submission with a noisy scan almost always comes back.

Tekunda builds and ships AppExchange packages through this process, so we run these scans before every submission rather than after a rejection. If you want a partner who has passed the review repeatedly, start here.

FAQ

Is Salesforce Code Analyzer enough on its own?

No. Code Analyzer is required, but you must also run the Checkmarx source scanner, and dynamic testing is expected for any external endpoint your package calls.

What replaced the Chimera scanner?

Nothing from Salesforce. Since Chimera was decommissioned in June 2025 you run your own dynamic scan with a tool such as OWASP ZAP or Burp Suite and attach the report.

Which Code Analyzer version does the review require?

Version 5. It is generally available and built into the Salesforce CLI; version 4 was retired in August 2025, so point your pipeline at v5.

Salesforce OAuth Flows: Choosing the Right Authentication Design

Tekunda Team — Wed, 16 Sep 2026 07:41:34 GMT

How do you choose the right Salesforce OAuth flow? Send a human through the Authorization Code Flow with PKCE, wire a server-to-server job to the JWT Bearer Flow (or the Client Credentials Flow), and never fall back to a username, password, and security token because it is quicker to stand up. That last shortcut is now on a countdown. Salesforce announced the retirement of the OAuth 2.0 username-password flow for connected apps in Spring '26, originally listed it for enforcement with the Winter '27 rollout, then pinned it to a single fixed date: 20 February 2027. That date is the same for every org on the platform, not tied to your instance upgrade weekend, so there is no staggered window to hide behind. Orgs created in Summer '23 or later already block the flow outright. Get the design wrong and you either lock legitimate integrations out of your org or leave a long-lived credential where an attacker can find it.

How do you choose the right Salesforce OAuth flow?

Every OAuth decision starts with one question: is a person authorizing this connection, or is a machine?

If a person is present, route them through the Authorization Code Flow with PKCE (Proof Key for Code Exchange), which Salesforce documents as the OAuth 2.0 web server flow with the PKCE extension and now names as its recommended replacement for user-based logins. PKCE binds the authorization code to the client that requested it, so a code intercepted in transit is useless to an attacker. Prefer it over the OAuth 2.0 Device Flow, which Salesforce has been pulling back: it removed Device Flow support from the auto-installed Data Loader connected app on 2 September 2025, and Data Loader 64.1.0 dropped both the Device Flow and the User-Agent Flow. Both were easy to abuse because they could be kicked off with little more than a client ID, a favorite target for social engineering.

If no person is present, such as a nightly ETL job or middleware pushing records into Salesforce, choose a server-to-server flow: the JWT Bearer Flow or the Client Credentials Flow. Both let a backend service authenticate without a browser or a session to redirect. The same either-or choice sits underneath most of the integration architecture patterns that actually scale, because the authentication design has to survive every retry, timeout, and credential rotation those patterns throw at it.

JWT Bearer vs Client Credentials: which server-to-server flow?

Both flows authenticate the app itself with no user in the loop, but they trade differently on secret handling.

JWT Bearer Flow authenticates with a digitally signed certificate instead of a shared secret. There is no client secret sitting in a config file to leak, the signed assertion is short-lived, and rotating the key means swapping a certificate rather than redeploying code. Reach for this when you want the strongest posture and can manage a private key.
Client Credentials Flow exchanges a consumer key and consumer secret for an access token and runs as a designated integration user. It is simpler to set up, but the secret is a bearer credential: anyone who intercepts it can impersonate the integration, so it has to be stored and rotated with real discipline.

Whichever you pick, scope the running or integration user tightly with a dedicated profile and permission sets instead of granting broad admin access for convenience. A machine account that can only touch the objects it needs is the difference between a contained incident and a full-org compromise.

Connected Apps vs External Client Apps: what changed for 2026?

Salesforce has been splitting the classic connected app into two purpose-built app types, and the timeline now forces the decision. As of Spring '26, Salesforce blocks the creation of new connected apps through both the UI and the API, with package installation the only exception, and recommends external client apps instead. Existing connected apps keep working during and after the change - nothing in your org breaks on the upgrade weekend. If you genuinely must create a new connected app, Salesforce Support can re-enable creation for your org for now, but Salesforce has said that ability will be removed in a later release, so it is a bridge, not a long-term plan.

External client apps are the newer, recommended path for any external system authenticating into Salesforce over OAuth, including your own middleware, ETL tools, and partner integrations. They take a deliberately stricter stance: they support the secure OAuth flows only and exclude the username-password flow entirely. They also support the Metadata API fully and keep consumer secrets out of packaged components, which makes them far easier to manage through source control and CI/CD pipelines than a legacy connected app.

The practical takeaway in an architecture review: default to an external client app for new integrations, and reserve connected apps for the Salesforce-native cases that still need them, such as canvas and mobile publishing. Reaching for a legacy connected app out of habit now means running into a creation restriction on your next build.

Where do Named Credentials fit into a secure integration design?

Named Credentials solve a different problem: outbound callouts from Salesforce to external systems, driven by Apex or Flow. Instead of hardcoding an endpoint URL and OAuth details inside a class, you register a Named Credential once and reference it by name, scoped per user or org-wide, and Salesforce handles the token exchange and refresh behind the scenes.

This matters for security review because it removes credentials from code entirely. Whether the underlying handshake is JWT Bearer or Client Credentials, the secret or key lives outside your integration code, so rotating it happens in one place instead of hunting through Apex classes and Flow definitions. When you connect Salesforce to a heavyweight system of record like an ERP, this is what keeps the Salesforce and SAP integration patterns auditable rather than a pile of embedded passwords.

How do you migrate legacy username-password integrations to modern OAuth flows?

Most orgs we review still have at least one integration authenticating with a username, password, and security token, sometimes from a script nobody remembers writing. The 20 February 2027 cutoff already slipped once, from the Winter '27 enforcement list, so treat the extra runway as migration time rather than a reprieve. There is no deprecation banner in the UI: on the cutoff date, a password-based integration simply stops receiving an access token and starts returning an authentication error. A structured migration looks like this:

Inventory every integration user and API-enabled profile to find where password-based logins are still in use.
Classify each integration as user-present or server-to-server, then map it to Authorization Code Flow with PKCE, JWT Bearer Flow, or Client Credentials Flow.
Register a dedicated External Client App per integration rather than sharing one app across unrelated systems.
Move outbound callouts behind Named Credentials so secrets live outside the codebase.
Rotate the old integration user's password and revoke its API access once traffic has fully cut over.

Sequence the cutover integration by integration, confirming each connection authenticates in a sandbox before touching the credential production depends on. The same authentication design also underpins newer patterns like running CRM actions from an agentic hub, where a single machine identity fans out across many actions and a leaked secret would be that much more damaging.

This is the kind of work our consulting team handles regularly. If your org still runs password-based integrations, we can map the migration path well before 20 February 2027 turns it into a fire drill. Get in touch to talk through your setup.

FAQ

When is the Salesforce username-password OAuth flow retired?

Salesforce moved the retirement from the Winter '27 rollout to a single fixed date, 20 February 2027, which applies to every org at once rather than following each org's upgrade weekend. Orgs created in Summer '23 or later already block the flow. Migrate affected integrations to the web server flow with PKCE, the JWT Bearer Flow, or the Client Credentials Flow before then.

Can I still create a new Connected App in 2026?

Salesforce restricts creation of new connected apps as of Spring '26 and recommends external client apps instead. Existing connected apps keep working, and you can request an exception through Salesforce Support if you truly need one.

What is the difference between JWT Bearer and Client Credentials flows?

Both are server-to-server flows with no user present. JWT Bearer authenticates with a signed certificate and has no shared secret to leak, while Client Credentials exchanges a consumer key and secret and runs as a designated integration user, which is simpler but relies on a bearer secret you must store and rotate carefully.

Should new integrations use Connected Apps or External Client Apps?

Default to external client apps for new external integrations. They support only the secure OAuth flows, work fully with the Metadata API for CI/CD, and are the path Salesforce now recommends. Reserve connected apps for Salesforce-native cases like canvas and mobile publishing.

Do Named Credentials replace OAuth flows?

No. Named Credentials manage outbound callout authentication and can use OAuth flows like JWT Bearer under the hood, keeping secrets out of Apex and Flow rather than replacing the flow itself.

Salesforce Code Analyzer v5: Moving Your Pipeline Off sfdx-scanner

Tekunda Team — Wed, 05 Aug 2026 12:00:00 GMT

TL;DR: Salesforce Code Analyzer v5 replaces the sfdx-scanner plugin. Install it with sf plugins install code-analyzer, swap sf scanner run for sf code-analyzer run, and replace the old --engine and --category flags with a single --rule-selector. The Graph Engine moves under the same command, and engine tuning moves out of CLI flags into a code-analyzer.yml.

If your CI still shells out to sf scanner run, this is the migration to schedule before your next AppExchange submission, not after. The rest of the security review does not change, so this guide sticks to the tooling swap. For what reviewers actually reject and in what order to fix it, see Salesforce Security Review Checklist: What to Fix, In Order.

What changed between sfdx-scanner and Code Analyzer v5?

Same job, new front door. Code Analyzer v5 is a sf plugin that unifies the static analysis engines behind one command and one result format, instead of the engine-by-engine flags v4 exposed. Three differences matter when you migrate:

One command surface. sf code-analyzer run covers the engines that used to be split across sf scanner run and sf scanner run dfa, so the Graph Engine is no longer a separate invocation with its own flags.
Selectors instead of engine and category flags. You ask for rules by name, tag, engine or severity through --rule-selector rather than combining --engine with --category.
Configuration in a file. Engine tuning that used to live in CLI flags and per-engine config paths now belongs in a code-analyzer.yml, which you commit alongside the code it governs.

How do you install and run it?

Install the plugin, then run it against your workspace:

sf plugins install code-analyzer
sf code-analyzer run --workspace . --view detail

Generate a starting configuration once and commit it, so every developer and every CI job analyses with the same rules:

sf code-analyzer config --output-file code-analyzer.yml

Before you trust a selector, list what it resolves to. This is the fastest way to catch a migration that silently narrowed your coverage:

sf code-analyzer rules --rule-selector Security

How do you translate your existing commands?

Work through your pipeline definitions and your local scripts in one pass:

sf scanner run --target force-app becomes sf code-analyzer run --workspace force-app.
--engine pmd --category Security becomes --rule-selector pmd:Security, or just --rule-selector Security when you want that tag across every engine.
sf scanner run dfa becomes a selector on the Graph Engine inside the normal run, rather than its own subcommand.
--format plus --outfile become --output-file, where the extension picks the format. Use --output-file results.sarif if you upload findings to your host's code scanning view.
Per-engine config flags become entries in code-analyzer.yml. Move them rather than reproducing them as flags.

Do not migrate a suppression list by hand-copying rule names. Rule identifiers moved with the engines, so re-derive your exclusions from a fresh sf code-analyzer rules listing and delete the ones that no longer resolve.

How do you gate CI on the results?

Use --severity-threshold. The command exits non-zero when it finds a violation at or above the level you pass, which is what turns the scan from a report into a gate:

sf code-analyzer run --workspace . \
  --rule-selector Security \
  --severity-threshold 3 \
  --output-file results.sarif

Set the threshold where your codebase is today, not where you want it, then tighten it once the backlog clears. A gate that fails on every pull request from day one gets disabled within a week, and a disabled gate catches nothing.

What does this migration not change?

Code Analyzer covers the code inside your package. The rest of the submission evidence is untouched by the version swap:

The source scan you run through the Partner portal still runs separately.
Any external endpoint your package calls still needs its own dynamic scan report. See Running Your Own Dynamic Scans After Chimera.
Findings you consider false positives still need a written justification per finding. How to Document False Positives for the Salesforce Security Review covers the format.

Migrating a pipeline you did not build, on a deadline? Tekunda builds and packages AppExchange products as a Salesforce PDO, security review included. Tell us where your pipeline is stuck and we will scope the swap.

FAQ

Is sfdx-scanner still supported?

Treat it as the previous generation. Code Analyzer v5 is the successor, and new rules and engine updates land there, so a pipeline left on the old plugin quietly falls behind on coverage.

Do my results change after migrating?

Expect them to. Selectors resolve to a different rule set than your old engine and category combination, and severities are normalised across engines. Run both versions once, side by side, and diff the findings before you delete the old job.

Where do I put engine settings now?

In code-analyzer.yml, committed to the repo. Generate a starting file with sf code-analyzer config and edit from there rather than writing one from scratch.

Can I run it in a pipeline without the whole Salesforce CLI?

It is a sf plugin, so the CLI is a prerequisite. Install the CLI and the plugin in your build image rather than on every run, or the install dominates the job time.

How the AppExchange Security Review Submission Loop Works

Tekunda Team — Sun, 02 Aug 2026 12:00:00 GMT

The AppExchange security review is a loop, not a gate. You self-assess, submit, get a findings report back, remediate, and resubmit until Salesforce signs off. Knowing what each lap costs, and which findings force one, is what turns a multi-cycle slog into a single pass.

Tekunda takes managed packages through AppExchange security review as a Salesforce PDO. What follows is the loop as we run it.

What happens after you hit submit?

Your submission joins a queue, then three lenses run against it: static code analysis with the Salesforce Code Analyzer, dynamic testing against a running org, and a manual review by Salesforce's product security team. What comes back is a findings report, not a verdict, and every line on it either gets fixed or gets a written explanation. Salesforce states that a solution typically takes 4 to 5 weeks to get through the review, and that for every paid solution sold on the marketplace there is a $999 fee for the initial submission and for any subsequent attempts. That is what makes an extra lap expensive: another invoice, and another trip through the same queue.

What do you fix before the first lap?

Everything a scanner can find without help. Access control enforced in user mode, sharing declared on every Apex class, bind variables instead of concatenated SOQL, escaped output, and secrets in Named Credentials or protected custom metadata rather than in code. The full list, in the order that costs least to work, is in Salesforce Security Review Checklist: What to Fix, In Order. A finding you could have caught yourself is the most expensive kind, because it buys a whole extra lap.

How do you run the loop, step by step?

Self-assess. Run the Code Analyzer and your own dynamic scan, triage every finding, and fix the real ones. Salesforce retired the hosted Chimera scanner on 2025-06-16, so the dynamic scan is yours to run now. See Running Your Own Dynamic Scans After Chimera for the accepted tools and the report to attach.
Document what is left. Every finding you are not fixing needs its own written justification: scanner and rule, file and line, the data path, and the control that protects it. How to Document False Positives for the Salesforce Security Review covers the format reviewers accept.
Assemble the submission. Work the Security Review Requirements Checklist in the Partner Community: scan reports, the false positive document, usage and data flow documentation, credentials for every external system, and a Developer Edition org with seeded data a reviewer can actually drive.
Submit, then leave the version alone. The queue is not a place to keep iterating. Freeze the package version you submitted and keep developing on a branch, so the reviewer and your team are never reading different code.
Remediate against the report. Treat it as a punch list, and fix each item at its root rather than at the symptom the scanner reported, because the next scan runs against the whole package again.
Resubmit with evidence. Answer every finding explicitly, including the ones you disagreed with, and say where the fix lives. Unanswered items are what turn a second lap into a third.

What sends a package around the loop a second time?

The same short list every time: missing CRUD/FLS checks, dynamic SOQL built from input, unescaped output, cross-site request forgery, insecure direct object references, and Apex classes that never declared sharing. Almost all of them are catchable in self-assessment. The other repeat offender is procedural rather than technical, a stale or unexplained scan report or a test org the reviewer cannot log into, which stalls the lap before the code is even read.

Where Tekunda fits

Listed packages are re-reviewed periodically, so the loop never fully closes. Keeping a living remediation log, and rerunning the scans on every release instead of every submission, is what makes the next lap a formality. If you would rather the review was handled by people who have cleared it before, Tekunda builds and packages AppExchange products as a Salesforce PDO.

FAQ

How long does the AppExchange security review take?

Salesforce states that a solution typically takes 4 to 5 weeks to get through the review. A resubmission re-enters the same queue, so plan a second lap into the release schedule rather than assuming a fast track.

How much does the security review cost?

Salesforce documents a $999 fee for every paid solution sold on the marketplace, charged for the initial submission and for any subsequent attempts. A clean first pass is the only way to pay it once.

Is the Salesforce Code Analyzer scan mandatory?

Yes, for managed packages listing on AppExchange. Upload the Code Analyzer results with your submission, alongside a dynamic scan report for every external endpoint your package calls.

What replaced Chimera for dynamic scanning?

Nothing hosted. Since Chimera was retired on 2025-06-16, partners run their own dynamic application security testing with tools such as OWASP ZAP, Burp Suite or Qualys and submit the report.

Do I have to repeat the review?

Yes. Listed packages are subject to periodic re-review, so build remediation and documentation into your release process rather than treating security as a one-time event.

How to Document False Positives for the Salesforce Security Review

Tekunda Team — Sat, 01 Aug 2026 12:00:00 GMT

TL;DR: A false positive is a scanner finding that flags code that is not actually vulnerable. Salesforce does not want you to silence it, it wants a written justification for each one: the scanner and rule, the exact file and line, the data path, and the control that already protects it. Vague, one-line dismissals are the most common reason a false-positive document comes back with questions.

Every AppExchange security review submission includes scan reports, and no real codebase scans perfectly clean. Some findings are true issues you fix. Others flag code that is already safe, and those you document. This guide is about the second group: how to write false-positive justifications the Salesforce security review team accepts, and the mistakes that get them rejected. For the failures you should actually fix, and the order to fix them in, see Salesforce Security Review Checklist: What to Fix, In Order.

What counts as a false positive?

A false positive is a finding that is technically wrong for your code, not one you would rather not deal with. A scanner flags a pattern; whether that pattern is exploitable depends on context the scanner cannot always see. If the code is genuinely protected, you have a false positive to document. If you are not sure it is protected, treat it as a real finding and fix it, because guessing here is what turns a document into a rejection.

The categories that recur often enough to plan for are:

Access-control findings raised against code that already runs in user mode with WITH USER_MODE or AccessLevel.USER_MODE.
Sharing findings on classes only ever entered through a context that has already applied sharing.
Injection findings on queries that use bind variables the scanner did not trace.
Cross-site scripting findings on parameters that never reach the DOM or are encoded before they do.
Vulnerable-library findings matched on a version string inside a bundled static resource that the package never executes.

The bar is different for each scanner

Before you write a single justification, know which findings you even have to address. The threshold is not zero findings, and it changes by tool:

Salesforce Code Analyzer: resolve every security-related error, and disregard findings that are not security related. Read the tool docs at Salesforce Code Analyzer.
Source scanner: address Low, Medium and High findings, and leave purely informational warnings alone.
Dynamic (DAST) scanners: address everything except informational items and warnings, and keep a screenshot proving the correct endpoint was scanned.

Anything above the noise line is either fixed or documented. There is no third option where you ignore it silently.

What Salesforce asks for in the false-positive document

Salesforce asks for a document explaining why each flagged item does not pose a security risk, and it tells you to be specific about how you protect against the vulnerability the scanner indicated. Being right is not enough. The document is what the reviewer reads, so the document is what has to prove it.

What a good entry looks like

Give every flagged item its own entry rather than one blanket paragraph. A strong entry answers, in order:

Which finding. The scanner name, the rule or category identifier, and the severity it assigned.
Where. The exact file and line, so the reviewer can open it without hunting.
The data path. One sentence on how data reaches that line, and why the flagged pattern does not apply to it.
The control. The specific mechanism that protects it, named concretely: the bind variable, the user-mode enforcement, the encoding call, the sharing context.
Proof. Where that control lives in the package, and for dynamic findings, the screenshot showing the endpoint that was actually tested.

Write it so someone who has never opened your code can follow the path from input to the control and agree it is safe. That is the whole test.

Why false-positive documents get rejected

The rejections we see cluster into a handful of avoidable mistakes:

One-line dismissals. "Not exploitable" or "handled elsewhere" gives the reviewer nothing to verify, so it comes back as a question, and questions cost a review cycle.
No file and line. A justification the reviewer cannot locate in the code cannot be confirmed.
Documenting a real issue. Arguing a genuine finding is a false positive erodes trust in the entire document, and the reviewer starts re-checking the ones that were fine.
Missing dynamic-scan evidence. A DAST finding waved away without a screenshot of the scanned endpoint reads as untested, not safe.
Stale references. Line numbers that no longer match the submitted package because the code moved after the scan.

How metadata discipline makes this repeatable

Salesforce periodically re-audits listed packages, which means you will write false-positive justifications more than once. When your package metadata lives in source control, every permission set, sharing rule and named credential is versioned, so you can point to the exact control that backs a justification and show it has not changed. Teams that treat metadata as code reuse last year's document instead of reconstructing the reasoning from scratch.

If you would rather a partner who has cleared the review before writes these justifications with you, Tekunda builds and packages AppExchange products as a Salesforce PDO.

FAQ

Can I just suppress a finding instead of documenting it?

No. Anything above the scanner's noise threshold is either fixed or explained in the false-positive document. A suppressed finding with no justification reads as an unaddressed one.

How detailed does each entry need to be?

Detailed enough for a reviewer to locate the code and confirm the control without asking you. In practice that is scanner and rule, file and line, the data path, and the exact control that protects it.

Do dynamic-scan false positives need extra evidence?

Yes. Attach a screenshot proving the correct endpoint was scanned, otherwise the finding reads as untested rather than safe.

Salesforce Security Review: Running Your Own Dynamic Scans After Chimera

Tekunda Team — Fri, 31 Jul 2026 12:00:00 GMT

TL;DR: Salesforce retired its hosted Chimera dynamic scanner on 2025-06-16, so partners now run their own dynamic (DAST) scan and submit the results with their AppExchange security review. Point an accepted tool such as OWASP ZAP, Burp Suite or Qualys at a full install, keep proof you scanned the right endpoint, and document every finding you triaged. This guide covers what changed, which tools qualify, how to produce a submission-ready report, and the mistakes that send one back.

For years Salesforce ran the dynamic scan for you through Chimera. That service is gone. The static analysis and manual review are unchanged, but the dynamic scan is now yours to run and yours to evidence. This guide covers that one shift. For the failure modes that send submissions back and the order to fix them in, see Salesforce Security Review Checklist: What to Fix, In Order.

What changed when Chimera retired?

Chimera was Salesforce's hosted service that dynamically tested a partner's external endpoints during the review. Since it retired on 2025-06-16, partners submitting a managed package run their own dynamic scan against any service the package calls and attach the report to the submission. Salesforce still performs static analysis and manual review; only the dynamic testing moved to you.

If your package only ever calls Salesforce APIs and hosts nothing external, you may have little to scan. The moment your app talks to a service you operate, that service is in scope and needs its own report.

Which dynamic scan tools does Salesforce accept?

You pick the tool, as long as it produces a credible DAST report. The ones partners reach for most often are:

OWASP ZAP. Free and open source, and the usual starting point for a first submission.
Burp Suite. The professional edition covers most partner needs, with a stronger active scanner than the free tier.
Qualys WAS. A hosted option for teams that already run it elsewhere in their stack.
Other DAST tools such as Veracode, Acunetix, Intruder or JiT DAST are equally acceptable if your team already owns one.

Salesforce cares about the report, not the brand on it. Whatever you run has to show it reached and exercised the live endpoint.

How do you run a scan and document the results?

Stand up a full install of the package in a test org with realistic seeded data, so the scanner exercises real workflows rather than empty pages.
Authenticate the scanner as a real user, then let it crawl and actively scan every external endpoint the app calls. An unauthenticated scan misses most of the surface.
Capture a screenshot or log proving the scan hit the correct endpoint. Salesforce asks for evidence the right target was tested, not just a clean summary.
Triage every finding. Fix the real issues, and for each false positive write one entry: tool and rule id, the endpoint, the data path, and the control that protects it.
Export the full report plus your false-positive document, and attach both to the submission alongside your static scan reports.

What are the common pitfalls?

Scanning the wrong target. Pointing the tool at a staging URL the package never calls produces a report Salesforce cannot match to your app.
Skipping authentication. An unauthenticated scan never reaches the logged-in surface, so the report looks clean because it tested almost nothing.
Submitting raw output. A dump of findings with no triage reads as unreviewed. Every item needs a fix or a written justification.
Leaving it until the week before. Run the scan during development so findings surface while they are still cheap to fix.

Where Tekunda fits

Running and evidencing a dynamic scan is exactly the step that stalls a launch when a team meets it for the first time. Tekunda builds and packages AppExchange products as a Salesforce PDO, dynamic scan and submission included.

FAQ

Do I still need a dynamic scan after Chimera retired?

Yes, more than before. Chimera used to run it for you; now you run it yourself and submit the report with your package.

Which tool should I use?

Any credible DAST tool. OWASP ZAP is the free default; Burp Suite, Qualys and Veracode are common paid options. Salesforce judges the report, not the brand.

What if my package has no external endpoints?

Then there may be nothing to scan dynamically. As soon as the app calls a service you operate, that service is in scope and needs its own report.

When should I run the scan?

During development, not the week before you submit, so findings surface while they are still cheap to remediate.

Building a Salesforce Center of Excellence From Scratch

Tekunda Team — Mon, 27 Jul 2026 12:00:00 GMT

Short answer: a Salesforce center of excellence is a small team with real decision rights over the platform, not a committee that meets monthly to review other people's work. At mid-size you can build one with four part-time people and three artefacts. Governance fails when it is designed to prevent decisions rather than to make them quickly.

What is a Salesforce center of excellence, actually?

Strip away the enterprise vocabulary and a CoE is three things:

A named owner of the platform. One person who is accountable for whether Salesforce serves the business, not five who are consulted.
A short list of decisions that only they make. Data model, integrations, security model, release process.
A set of reusable assets so the next project starts at 60% rather than zero.

Everything else people put in a CoE charter is either a meeting or a document, and neither changes what ships.

Do you need one at mid-size?

Most CoE advice is written for orgs with thousands of users. You do not need the enterprise version, but you do need something the moment these signals appear:

Two departments have built overlapping objects that mean nearly the same thing.
Nobody can say what a change to Account will break.
Every project rebuilds the same integration or approval pattern from scratch.
Releases wait on one person's calendar.
The backlog is arbitrated by whoever escalates loudest.

Two or three of those and you already have a governance problem. You just have not named it yet.

Who is on the minimum viable CoE?

Four roles, and at mid-size most of them are part of somebody's existing job. Resist the urge to staff a department.

Platform owner (20-40%). Usually a product or ops leader. Owns the roadmap and says no. This is the role that cannot be shared.
Lead architect or senior admin (50%). Owns the data model, the security model and technical standards. Reviews changes that cross object boundaries.
Release owner (20%). Owns the pipeline, environments and the release calendar. Often the same person as the architect early on, but the responsibility should be written down separately.
Business representative per major function (10% each). Sales, service, finance. They bring demand and take decisions back to their teams. They are not there to approve technical work.

Four people, roughly 1.2 full-time equivalents. That is the whole thing. A CoE that needs six new hires before it can operate will be cancelled in the next budget round.

What decisions does the CoE own, and what does it not?

This is the part teams skip, and it is the only part that determines whether the CoE survives. Write two explicit lists.

The CoE decides: changes to shared objects and the data model, new integrations and the systems of record behind them, the security and sharing model, the release process and its gates, which capabilities get built as reusable components, and what goes on the roadmap.

The CoE does not decide: report and dashboard layouts, page layout tweaks inside one team's own objects, field label wording, or which of two equally valid implementations a developer picks. Those belong to the people doing the work.

The second list matters more than the first. A body that reviews everything becomes a queue, and a queue gets routed around. Within a couple of quarters people will be building in their own sandboxes and asking forgiveness, which is exactly the state you set the CoE up to end.

Why committees fail and small teams do not

A committee optimises for consensus, which means its default answer is delay. A team optimises for throughput, which means its default answer is a decision, sometimes a wrong one. On a platform where a wrong field can be renamed next sprint but a stalled roadmap costs a year, the team wins that trade every time.

Three rules keep it a team:

Decisions have a deadline. Anything not decided within one week defaults to the architect's recommendation. Silence is consent.
Meet weekly for 45 minutes, not monthly for two hours. Short cadence means small decisions, which are the reversible kind.
Publish decisions, not minutes. One line per decision, with the reason and the date. That log becomes the standards document nobody had time to write.

What should it produce in the first 90 days?

Days 1-30: the decision-rights document above, and an honest inventory of what exists. Objects, integrations, automation, technical debt, who owns what.
Days 31-60: the release process. One pipeline, one set of environments, approval gates by environment, and no direct changes in production.
Days 61-90: the first two reusable components. Pick the patterns you have already built twice, package them properly, and use them on the next project.

That third item is what turns a CoE from an overhead into an asset. Building products taught us this the hard way: at Tekunda we work as a Salesforce SI, ISV and PDO, and the packaging rigor from the product side is exactly what lets a delivery team bring new work live in weeks rather than months. A CoE that produces reusable parts pays for itself. A CoE that produces policy documents gets cut.

FAQ

How big should a Salesforce CoE be?

At mid-size, four roles totalling roughly one to one and a half full-time equivalents. Add people only when a specific decision keeps waiting on capacity.

Should the CoE sit in IT or in the business?

Neither exclusively. The platform owner should come from the business and the architect from IT, reporting jointly. A CoE owned entirely by IT drifts from demand, one owned entirely by the business drifts from architecture.

What is the difference between a CoE and a governance board?

A governance board reviews decisions made elsewhere. A CoE makes them and is accountable for the outcome. If your CoE only reviews, you built a board.

How do you know the CoE is working?

Time from request to production falls, the number of changes made outside the release process approaches zero, and each project reuses more than it rebuilds.

How to Prepare Your Salesforce Org for an Audit

Tekunda Team — Sun, 26 Jul 2026 12:00:00 GMT

Short answer: an auditor does not want a tour of your org. They want three evidence packs: who had access and who approved it, what changed in production and who signed it off, and how long you keep records before deleting them. If those three exports are routine, an audit is a meeting. If they are not, it is a two-week fire drill.

What does an auditor actually ask a Salesforce team for?

Most Salesforce audit advice describes an internal health check: dead fields, unused reports, storage cleanup. That is useful housekeeping, but it is not what an external auditor tests. Under SOX, SOC 2 or ISO 27001, they sample and ask you to prove a control:

Access evidence. A user list with profiles, permission sets and roles, plus who approved each grant and when it was last reviewed.
Change evidence. For a sample of production changes: the request, the approval, the test result and the deployment record.
Retention and deletion evidence. What personal data you hold, how long you keep it, and proof that deletion requests were honoured.

Almost every finding we have seen comes from one of those three, not from a messy page layout.

What is in scope, and who decides?

You decide first, then defend it. Scope follows risk, not the org chart:

Financial reporting (SOX): quoting, orders, billing, revenue objects and any automation that can change those values, including integration users.
Personal data (GDPR and similar): Contact, Lead, Case, Person Account, chat transcripts and every sandbox copy.
Privileged access: Modify All Data, View All Data, Manage Users, Author Apex, and anyone who can deploy.

Write this down as a one-page scope memo before the kickoff call. An auditor who has to define scope for you will define it generously.

How do you produce access evidence without screenshots?

Screenshots age badly and prove nothing about the other 51 weeks of the year. Export instead, on a schedule:

Query the permission objects. PermissionSetAssignment, ObjectPermissions and FieldPermissions give you the real picture, including everything granted through permission set groups.
Export Login History. Salesforce keeps six months online and lets you download it as CSV. Dormant accounts with live privileges are the classic finding.
Run Security Health Check and Optimizer and keep the output. Auditors accept a dated self-assessment as evidence that monitoring exists.
Do the review quarterly, with a named approver. An access review nobody signed is not a control. Record the reviewer, the date and the exceptions.

Integration users deserve their own line. They usually carry the widest permissions and the least scrutiny, and auditors have learned to look there first.

How do you produce change evidence?

This is where change sets hurt. They cannot separate the person who builds from the person who deploys, and they leave no linked approval. A pipeline answers with links: the work item and its business reason, the commit showing exactly which metadata moved, the pull request with a reviewer who is not the author, the test result, and the deployment record.

Two properties decide whether it passes. The evidence must be immutable, and it must be complete, meaning there is no route to production that bypasses it. A process covering most changes still fails, because the sample can land on the exception.

Native history helps but does not carry the whole load. Setup Audit Trail holds 180 days and is queryable through the SetupAuditTrail object before it is purged. Field History Tracking keeps roughly 18 months in the UI and 24 through the API, unless you licence Field Audit Trail with Salesforce Shield and set a retention policy. Audit cycles are annual, so keep your own copy in Git and your DevOps platform.

How do you prove retention and deletion?

Retention is the question teams answer worst, because nobody owns it. Three artefacts settle it:

A data map: which objects and fields hold personal data, and the lawful basis for each.
A retention schedule per object, with the deletion mechanism named (scheduled job, archive, hard delete).
A deletion log showing that erasure requests were executed, including in sandboxes and backups.

The sandbox line is the one that surprises people. A full sandbox refreshed from production is a copy of the same personal data in a less controlled environment. Seed a subset and mask personal fields as part of the refresh job, so the control evidences itself.

How do you prepare in two weeks instead of two months?

Days 1-2: write the scope memo and name an owner per evidence pack.
Days 3-5: export access data, run Health Check, list every integration user and privileged profile.
Days 6-8: pull 10 recent production changes at random and walk each one end to end. Whatever you cannot trace is your real finding.
Days 9-10: write the retention schedule and check sandbox data handling.
Then automate what you just did by hand, so next year is an export rather than a project.

That last step is the whole game. Teams that pass cleanly are not the ones with the tidiest org, they are the ones whose controls run on their own and leave a trail. Tekunda builds Salesforce this way as a certified SI, ISV and PDO, and we have taken managed packages through AppExchange security review in healthcare, logistics and manufacturing, where the evidence bar is set by someone else.

FAQ

How long does Salesforce keep setup change history?

Setup Audit Trail retains 180 days, then purges. Export it on a schedule or keep the equivalent record in your DevOps platform.

Do we need Salesforce Shield to pass an audit?

Not necessarily. Shield extends field history retention and adds Event Monitoring, which helps, but the controls and their evidence matter more than the licence.

How often should we run user access reviews?

Quarterly for privileged and integration users, at least annually for everyone else, with a named approver recorded each time.

Is a full sandbox with production data a problem?

It can be. Treat it as a processing activity: seed a subset instead of cloning, mask personal fields during the refresh, and restrict access as you would in production.

How to keep a Salesforce org secure as your team scales

Tekunda Team — Sat, 25 Jul 2026 12:00:00 GMT

Short answer: Salesforce orgs almost never become insecure because someone attacked them. They become insecure because permissions accumulate faster than anyone removes them, and because integration users are handed far more access than the integration needs. Both problems are silent, both scale with headcount, and both are fixed by design decisions rather than by security products.

What actually degrades Salesforce security as a team grows?

Two mechanisms, and neither of them looks like a breach on the day it happens.

Permission sprawl. Access is granted as a series of exceptions. Someone needs a report on Friday, gets a permission set, and keeps it for three years. Multiply by every hire, every project, every leaver whose access was never reclaimed.
Over-privileged integration users. The middleware needs to write to two objects, so it gets a System Administrator profile because that is the fastest way to make the sync work.

Both are additive by nature. Nothing in the platform removes access on its own. That asymmetry, easy to grant and nobody's job to revoke, is the entire story of how a well-designed org becomes an audit problem in two years.

Why does permission sprawl happen even in disciplined teams?

Because the fast path and the correct path point in different directions:

Cloning is easier than modelling. Cloning a profile takes a minute and creating a proper permission set group takes an afternoon, so orgs end up with dozens of near-identical profiles nobody dares consolidate.
Temporary access has no expiry. Salesforce will not take it back for you, and no ticket exists to remind anyone.
Nobody owns removal. Grants have a requester. Revocations have nobody, which is why access reviews get scheduled and then quietly skipped.
Sensitive permissions hide in aggregate. Two harmless permission sets can combine into an ability neither was meant to grant.

What permission model survives headcount growth?

The model that scales is boring and well documented. What matters is committing to it before you have 200 users, not after.

Minimal base profile. Give the profile only what every user in that licence type needs. No object access that belongs to a job function.
Permission sets for capabilities, not for people. A permission set should describe a task, so its name should survive the person who first needed it.
Permission set groups for roles, with muting where a group grants slightly too much. This is the mechanism that lets you assemble a role without cloning yet another profile.
Automate assignment with User Access Policies so joiners and movers get access from criteria rather than from memory.
Keep the dangerous permissions on a named list. Modify All Data, View All Data, API Enabled, export and Manage Users deserve an owner and a written justification per holder. If that list is longer than your leadership team, you have found your first project.

Salesforce Ben's walkthrough of least privilege is a good companion if you want the click-level detail. The design decision above is the part that has to come from you.

Why are integration users the biggest blind spot?

Because they are invisible in every conversation about security. They do not attend onboarding, they never leave the company, and nobody reviews them when a project ends. Meanwhile they typically hold broader data access than any human in the org and they authenticate without MFA prompts.

Four rules that hold up as the integration count grows:

One integration user per integration. Shared integration users make it impossible to answer who wrote a record, and impossible to revoke one system without breaking another.
Use the API-only integration licence where you can. Salesforce provides five free Salesforce Integration licences on Enterprise, Unlimited and Performance editions, with no UI access at all, which removes an entire class of misuse.
Scope to objects and fields, not to profiles. Write down what the integration is allowed to touch and enforce it with a permission set built for that integration alone.
Restrict by IP and monitor the volume. An integration user's behaviour is predictable, which means anomalies in it are unusually meaningful compared with human activity.

Which controls actually survive scale?

These are the ones that keep working when the team doubles, ordered by how much they repay the effort:

Deploy permissions through the pipeline, not by hand in production. If access changes are in version control, every grant has an author, a review and a date. This one control makes the next four possible.
Run a recurring access review with a named owner and a fixed agenda: the dangerous-permission list, integration users, and anyone whose role changed last quarter.
Set an expiry convention for exception access, even if you have to enforce it with a calendar reminder. Access with no end date is permanent access.
Track Health Check and Setup Audit Trail as a trend, not as a screenshot before an audit.
Include permissions in code review. A profile or permission set diff belongs under the same scrutiny as Apex, because it can do more damage faster.

How do you know it is working?

Pick metrics that go down. Count the holders of each dangerous permission. Count permissions granted outside a permission set group. Count integration users with UI access. Count profiles. If those four numbers are not falling quarter on quarter, your security posture is drifting even if nothing has gone wrong yet.

FAQ

Are profiles deprecated in Salesforce?

No, and you still need one per user. The practical guidance is to keep profiles minimal and to express everything role-specific through permission sets and permission set groups.

How often should access be reviewed?

Quarterly for dangerous permissions and integration users, and immediately on any role change or departure. An annual review is an audit exercise, not a control.

Do integration users need MFA?

API-only integration users authenticate system to system, so the meaningful controls are IP restrictions, scoped permissions and monitoring rather than an MFA prompt no human will ever see.

Is this a security tooling problem?

Tools help you see the sprawl. They do not decide who should have access. The decisions are architectural, which is why the fix belongs in your delivery process rather than in a product purchase.

We build on Salesforce as a certified SI, ISV and PDO, and we have taken packages through AppExchange security review in healthcare, logistics and manufacturing, so the permission model is something we design rather than inherit. If your org has grown faster than its access model, talk to us.

How connected-device teams cut support cases by 93 percent on Salesforce

Tekunda Team — Fri, 24 Jul 2026 12:00:00 GMT

Short answer: connected-device teams do not cut case volume by staffing support harder. They cut it by letting the device report its own fault, resolving most of those reports automatically, and reserving a Salesforce case for the exception that genuinely needs a person. On a programme we delivered for ASSA ABLOY (FocusCura and Phoniro), that model took weekly support cases from roughly 3,000 to 350, a 93 percent reduction, across 11,000 connected devices and up to 2.5 million events per week in three markets, with no added support staff.

What is telemetry-driven service?

Telemetry-driven service is a model where the asset opens the conversation instead of the customer. Device events flow into the CRM continuously, get matched to an asset and an entitlement, and trigger a resolution path before anyone picks up a phone.

Three levels are worth separating, because most teams collapse them into one word:

Reactive. The customer notices the fault and calls. Every incident costs an agent.
Proactive. The platform notices first and warns someone. Better for the customer, but a human still handles it.
Autonomous triage. The platform notices, classifies and remediates. A case exists only when the remediation fails.

Almost all of the 93 percent lives in the jump from proactive to autonomous. Proactive alerting on its own tends to increase workload, because you have added a queue without removing the old one.

How does a device event become a resolved incident without a case?

Ingest at event rate, not at case rate. Millions of weekly events belong in a data layer built for volume. Salesforce now calls that layer Data 360, the renamed Data Cloud that sits under Agentforce 360.
Resolve identity before anything else. Every event is matched to an asset record, its location, its customer and its entitlement. An event that cannot be attributed is an integration defect, not an incident.
Classify against a rule set. Signature patterns map to known fault classes with a known remedy: reboot, re-pair, firmware push, consumable order, dispatch.
Remediate automatically where the remedy is deterministic. Most field faults are a small set of repeats. Automate the repeats first and the long tail never becomes urgent.
Create a case only on escalation. The case is opened after automation has tried and failed, and it carries the full attempt history so the agent does not start from zero.
Dispatch through Field Service only when someone must physically attend, with the part and the diagnosis already attached to the work order.

Which device events deserve a case at all?

This is the question most published guidance on connected service skips, and it is where the number actually comes from. A case is a unit of human work, not a unit of telemetry. Sort every event signature into one of three buckets before you build anything:

Noise. Transient, self-correcting, no customer impact. Suppress it and count it. Never surface it.
Deterministic. Known fault, known fix, no judgement required. Automate end to end.
Ambiguous. Needs a person, a decision or a visit. This is the only bucket allowed to create a case.

Teams that skip this exercise end up with proactive alerting that generates more tickets than the old phone line did.

What did the 93 percent look like in practice?

ASSA ABLOY's connected-care business ran a fleet of 11,000 devices producing up to 2.5 million events a week across three markets. Support was absorbing around 3,000 cases a week, and the obvious answer on the table was to hire.

Instead the telemetry was routed into Service Cloud through an autonomous triage layer, and the fleet began resolving itself. Weekly cases settled at about 350. Support headcount did not move.

Two details matter more than the headline:

The cases that remain are harder, and that is correct. What is left is the ambiguous bucket. Expect average handle time per case to rise while total service cost falls, and have that conversation with your service director before go-live, not after.
Nothing was rebuilt per market. The device-to-Service-Cloud path shipped as a packaged 2GP component, which is what made the second and third market cheap rather than a repeat project.

What operating model makes the reduction stick?

Architecture gets you the first drop. The operating model is what stops it drifting back within two quarters.

Treat the rule set as product, not configuration. Version it in source control, review it, deploy it through a pipeline, and be able to roll it back. Rules edited live in production always rot.
Give service leadership ownership of thresholds. The people who feel the queue should be able to change what fires without waiting for a release.
Measure cases per thousand devices, not cases. Absolute case count flatters you when the fleet is flat and punishes you when you win customers. The ratio is the only honest signal.
Review the suppression list on a fixed cadence. Everything you silenced is a bet, and firmware changes turn good bets bad.
Keep one asset record. The moment device state lives in two systems, agents stop trusting the automation and start opening cases defensively.

Where does this usually go wrong?

Alerting without remediation. A dashboard of red tiles is a new job, not a saved one.
Storing every raw event as a platform record. Event volume and case volume are different orders of magnitude and belong in different places.
No entitlement in the path. Without contract context the automation cannot decide who pays for the visit, so it escalates everything to be safe.

FAQ

Do you need Data 360 to start?

Not for a pilot. You need a volume data layer when event rate outgrows what your core org should be storing, which for most fleets happens well before the millions-per-week mark.

Does this replace Field Service?

No. It reduces how many dispatches happen and improves the ones that remain, because the diagnosis and the part are known before the van leaves.

How quickly does case volume move?

The first measurable drop comes from the deterministic bucket, which is also the smallest build. Sequence that first and you get proof before you get scope.

Will Agentforce do this out of the box?

Agentforce reasons over the context you give it. It does not invent your fault taxonomy, so the classification rules, asset data and entitlement model still have to exist underneath.

We build this pattern as Tekunda IoT Cloud: device events to autonomous triage on Service Cloud, Field Service dispatch, grounded in Data 360. If you run a connected fleet and your case queue grows with your install base, talk to us.

How to Scope a Salesforce Project So It Ships on Time

Tekunda Team — Thu, 23 Jul 2026 12:00:00 GMT

A Salesforce project ships on time when the scope prices the decisions the project needs, not the features it will build. Most fixed-scope projects slip because discovery produced a feature list, and a feature list is silent about who has to decide what, and by when. The fix is an outcome, a decision register, and a written list of non-goals.

Why do fixed-scope Salesforce projects slip?

Not because the build was underestimated. Build estimates are usually close. The calendar breaks somewhere else.

The numbers are unkind. In its 2025 CRM failure research, Johnny Grow found that 55% of CRM deployments did not achieve their planned objectives, roughly 30% met their planned timeline, and only 25% hit objectives, timeline and budget together. Seven in ten overran the timeline by 30% or more. Those overruns are rarely engineering overruns.

Here is the actual mechanism. A scope line says "build an approval process for discounts over 15%". The build is three days. The unanswered question underneath it is who approves, at what threshold, in which currency, what happens when that person is on leave, and whether Finance or Sales owns the exception. That question needs four people in a room who are hard to get in a room. It does not go faster if you add developers. The project waits, and the wait lands on the delivery date.

What does it mean to price decisions instead of features?

A feature is work. A decision is a dependency on a human being. Scoping that only counts the work produces an estimate that is right about the build and wrong about the calendar.

Your scope was priced as features if:

Every line starts with build, configure or migrate.
No line names a person who has to decide something.
Integration lines do not say which system is the source of truth for each object.
Data migration is one line.
There is no non-goals section.

Each of those is a place where an unmade decision is hiding behind an estimated task.

How do you scope a Salesforce project so it ships on time?

Write one outcome sentence, with a number and a date. Not "improve service efficiency" but "cut weekly manual case triage from X to Y by the end of Q2". If nobody will commit to a number, you do not have a project yet, you have an interest.
Build a decision register before a task list. Every open question that blocks a build, with a named owner and a date it must be answered. This is the document that predicts your go-live, not the Gantt chart.
Split known from unknown. Work you have done before gets an estimate. Work you have not gets a timebox and an explicit exit condition. Never average the two into one number.
Write the non-goals down and get them read aloud. See below.
Slice to a first release a real user group uses in production. One team, one process, live. A pilot that nobody depends on teaches you nothing about the decisions you got wrong.
Fix the cadence, not the scope. Two-week sprints with working software at the end of each is what lets you trade scope without renegotiating the contract. That is how we run engagements at Tekunda, and it is why a fixed date survives a changed requirement.

What belongs in a non-goals list?

A non-goal is something a reasonable person would assume is included, written down as excluded. It is the cheapest artefact in the project and the one most often skipped.

Things stakeholders asked for that are not in this release, named, not summarised.
Silent assumptions: historical data beyond a stated cutoff, offline mobile, a second language, a second country's tax rules.
Processes that stay outside Salesforce for now.
Integrations that will be one-way in this release even though everyone pictures two-way.

The rule that makes it work: a non-goal only counts if the person who asked for it has seen it in writing and not objected. A non-goals list nobody read is just a defence exhibit for the post-mortem.

How do you handle the request that arrives in week six?

It will arrive, and refusing it outright is usually the wrong answer, because week-six requests are often better informed than week-one requests. Ask two questions:

Does it change the outcome number? If yes, it is a re-scope and needs the sponsor.
Does it invalidate a decision already made and built on? If yes, price the rework separately and visibly.

If neither, trade it. Something of comparable size leaves the release and moves to the non-goals list, in writing, the same day. Adding without subtracting is how a date quietly dies.

What does a scope document that survives contact contain?

One outcome sentence with a metric and a date.
A decision register: question, owner, due date, status.
Assumptions, each one falsifiable.
Non-goals, named and acknowledged.
Data scope: which objects, how far back, who owns cleansing.
System of record per object, and the direction of every integration.
Definition of done for the first release, in user terms.
What happens after go-live, including who holds the backlog.

Eight items. It fits on two pages, and it will tell you more about your delivery date than a three-hundred-line requirements matrix.

FAQ

How long should Salesforce discovery take?

Long enough to close the decisions that block the first release, and no longer. Judge it by the state of the decision register, not by a fixed number of weeks.

Is fixed-scope always the wrong model for Salesforce?

No, but it only works when the decisions are already made. Fixed scope on an undecided process fixes the wrong variable and the date pays for it.

What is the difference between a non-goal and out of scope?

Out of scope is contractual. A non-goal is communicated. The value is in the stakeholder having read it, not in it being defensible later.

Who should own the decision register?

Someone on the client side with the authority to escalate. If your delivery partner owns it, every overdue decision becomes a vendor complaint rather than an internal deadline.

Can phasing fix a scope that is too big?

Only if each phase goes live to real users. Phases that all land at the end are one project with extra documents.

How to Run a Successful Salesforce Data Migration

Tekunda Team — Wed, 22 Jul 2026 12:00:00 GMT

Short answer: a Salesforce data migration is decided in the data-quality phase, weeks before load day. Profile the source data, decide deliberately what not to move, map every field with an external ID behind it, then rehearse the cutover until it is boring. Loading is the easy part, and it is almost never what goes wrong.

Why do Salesforce data migrations actually fail?

Rarely because of the load. Data Loader, Bulk API and the ETL tools all work. Failures trace back to decisions dodged earlier:

No named owner for a data domain, so nobody could approve a rule.
Duplicates that everyone saw and nobody agreed how to resolve.
A source field whose meaning drifted years ago and was mapped on its label.
A scope that quietly became "everything", because deleting nothing felt safer than choosing.

All four are cheap to fix in week two and brutal on cutover night. That is the whole argument for front-loading data quality.

What does profiling actually mean here?

Profiling is measurement, not inspection. Before anyone writes a mapping row, produce numbers for each source object:

Fill rate per field. A field populated in 4% of records is not a field, it is a rumour.
Distinct values against the target picklist. This is where "Prospect", "prospect" and "PROSPECT " become three values and one argument.
Duplicate rate on the intended matching key. Measure it before you choose the key, not after.
Orphan rate on every relationship. Child records with no resolvable parent decide your load order and your error volume.
Owner resolution rate. What percentage of records map to an active Salesforce user, and who gets the rest.
Date ranges and outliers. Records dated 1900 or 2099 fail a validation rule at the worst moment.

The output is a short profile report. Its real job is turning opinions into numbers, so scope conversations end in a decision instead of a meeting.

What should you decide not to migrate?

This is the highest-leverage decision in the project and the one most plans skip. Every record has four possible fates, and only one of them is expensive:

Migrate. It is needed operationally, in Salesforce, by a named process.
Summarise. The history matters as an aggregate, not row by row. Load a rollup, not ten years of transactions.
Archive. Keep it in a warehouse or export for compliance, out of the CRM.
Leave it. Keep the legacy system read-only for a defined period and let people look things up.

Sensible defaults: closed records older than your reporting horizon get summarised, contacts with no activity and no reachable email get archived, and free-text fields nobody reports on do not come across at all. Every record you exclude removes mapping effort, validation failures, test cases and post-go-live support. Reduced scope is the cheapest performance improvement available.

How do you build a mapping that survives contact with the data?

One row per target field, carrying: source field, transform rule, default value, owner, the validation it must pass, and the sign-off date. A row with no owner is not a mapping, it is a hope.

Two technical decisions determine how calm the rest of the project is:

Put an external ID on every object you load. It carries the legacy key, so parent-child relationships resolve without Salesforce IDs, upsert makes loads idempotent, and a re-run is safe. Without it, every retry risks duplicates.
Choose the matching key before you write a single transform. Email, tax number, legacy ID, or a composite. The profile report tells you which of them is actually unique in your data.

Then decide, in writing, which automation is suspended during the load and who turns it back on: validation rules, triggers, flows, assignment rules, duplicate rules and email alerts. An unplanned welcome email to 40,000 migrated contacts is the classic version.

How many dry runs, and what do you measure?

Three, minimum, in a sandbox that resembles production.

Shape run. Does it load at all? Field types, required fields, picklist values, record types.
Correctness run. Validate relationships rather than row counts. Matching totals with broken parents is the most reassuring failure mode in this whole discipline.
Timed run. Full volume, measured end to end, so the cutover window is a number you observed rather than one you estimated.

Keep every error log and treat the error rate as a trend. If run three is not materially cleaner than run one, the mapping is not converging and the go-live date is fiction.

What belongs in the cutover plan?

A cutover plan is a sequence with clock times and an owner per line, not a narrative:

Freeze the source system and announce the freeze to users, not just to the project channel.
Take the final delta extract.
Suspend the automation on the agreed list.
Load parents before children, in the declared order, in waves that isolate errors.
Re-enable automation and confirm each item is back on.
Run reconciliation queries: counts per object, orphan checks, spot checks on named records that business users chose in advance.
Business sign-off against those named records, then go or no-go.
Unfreeze, or execute the rollback.

Define rollback before cutover night, while it is a design question and not a panic. In practice: keep the legacy system authoritative and read-only until sign-off, and keep an external ID on every migrated record so a targeted delete or full re-load stays possible. Then staff the first 48 to 72 hours properly, because day-one questions reveal what the profile report missed.

We run migrations this way on client delivery, and it is part of how we have taken 20+ organisations live in production. Scoping one and want a second opinion on the data before a date is committed? Start here.

FAQ

How long does a Salesforce data migration take?

The load takes hours. The project takes as long as data-quality decisions take, which is why the timed dry run, not the plan, should set your cutover window.

Should we clean the data in the source system or during the load?

In the source where the owners are, wherever possible. Transform rules in a load script are invisible to the business and get re-litigated after go-live.

Do we need external IDs if we migrate only once?

Yes. They make retries safe, resolve relationships without Salesforce IDs, and are what makes a rollback or a targeted re-load possible later.

How much history should we bring across?

Only what a named process or report uses. Summarise the rest and archive the remainder outside the CRM: history is the most common source of scope creep here.

Salesforce Technical Debt: How to Find It and Pay It Down

Tekunda Team — Tue, 21 Jul 2026 12:00:00 GMT

Short answer: Salesforce technical debt is the accumulated cost of every past shortcut still sitting in your org, in clicks as much as in code. You find it with a full metadata inventory joined to usage data. You pay it down in the order your roadmap demands, not top to bottom, because debt that blocks nothing on the roadmap can wait, sometimes indefinitely.

What is Salesforce technical debt?

Technical debt is the extra work a future change will cost because of a decision taken earlier. On Salesforce it accumulates faster than on most stacks, for two structural reasons: a change is one admin and five clicks away, and nothing in the platform expires when people stop using it.

It arrives in four shapes:

Automation debt. Workflow Rules, Process Builder processes and Flows doing overlapping work, in a firing order nobody can draw on a whiteboard.
Configuration debt. Fields nobody has filled in two years, layouts for roles that no longer exist, profiles carrying permissions that belong in permission sets.
Code debt. More than one trigger per object, tests written to reach a coverage number rather than to assert behaviour, hardcoded IDs.
Integration debt. Callers pinned to API versions the platform no longer serves, and middleware whose owner has left the company.

Only the fourth kind breaks loudly. The other three quietly tax every project you run.

Where is it hiding right now?

Two dated items are worth checking this week, because the platform moved and most orgs did not.

Workflow Rules and Process Builder are past end of support. Salesforce set that date at 31 December 2025. Anything still on them keeps running, but bugs will not be fixed and you cannot build new ones. The Migrate to Flow tool exists for exactly this.
Legacy API versions are gone. Platform API versions 21.0 through 30.0 across SOAP, REST and Bulk were deprecated in Summer '22 and retired with Summer '25. Callers now receive 410 GONE on REST, 500 UNSUPPORTED_API_VERSION on SOAP and 400 InvalidVersion on Bulk. If an old nightly job went quiet, check this first.

How do you inventory debt without stopping delivery?

Run Salesforce Optimizer and export it. Free, in Setup, and it hands you a starting list rather than an opinion.
Retrieve the org metadata into source control. Even if you never deploy from it, you now have something to grep, diff and count.
Join the inventory to usage. Field history, report and dashboard subscriptions, page views, Apex logs. A field with no reads and no writes in twelve months is a candidate; the same field on an object carrying 400 others is a priority.
Map dependencies before you delete anything. The where-is-this-used question is the entire difference between a cleanup and an outage.
Name an owner per area. Debt with no owner is never paid.

For a mid-sized org this is a two-week exercise that runs alongside a normal sprint. What it produces is a register, not a project plan.

How should you rank what you found?

This is where most debt programmes go wrong. Ranking by severity orders the list by how bad things look; ranking by effort orders it by how easy they are. Neither is a list your business will fund twice.

Rank against the roadmap instead. For every item in the register, ask one question: which committed roadmap item does this make slower, riskier or impossible? That single question sorts the register into three tiers.

Blocking. The roadmap item cannot ship until the debt is paid. Do the work inside that project, funded by that project, with its business case.
Taxing. The roadmap item ships anyway, but costs more or carries risk it should not. Do it in the sprint before, tightly scoped.
Dormant. Nothing on the roadmap touches it. Log it, monitor it, do not fund it.

Two categories override the ranking: anything with a security or compliance consequence, and anything failing silently in production. Those are fixed regardless of what the roadmap says, because their cost is not paid in delivery time.

Why does wholesale cleanup fail?

Three reasons, and we have watched all three.

No visible outcome. An org-wide cleanup produces no feature and no number a sponsor can point at, so it loses its budget the first time priorities are re-cut.
Attribution damage. Deleting metadata nobody was watching causes an incident, the incident gets attributed to the cleanup, and the next one never gets approved.
It never converges. An org that shipped all year has fresh debt before the sweep finishes. Pay-down attached to roadmap items ends when the item ships.

The goal is not a clean org. It is an org where the next twelve months of roadmap can be delivered at a predictable cost.

What cadence actually works?

Every sprint. A fixed slice of capacity, commonly 10 to 20%, spent on taxing debt in the areas the next stories touch.
Every Salesforce release. Three times a year, re-run Optimizer, re-read the retirement notices and re-check the API versions your integrations request.
Every year. Refresh the inventory and re-rank against the new roadmap. Dormant debt sometimes becomes blocking overnight.

One preventive control outperforms all three: deploy from source control, so org state is reproducible and every change arrives with an author, a reason and a test. Debt you can see in a diff rarely becomes debt you discover in an incident.

We run this inventory at the start of engagements rather than after the first surprise, which is part of how we have taken 20+ organisations live on Salesforce. Want a second opinion on your org before committing next year's roadmap? Start here.

FAQ

How do I know if my org has too much technical debt?

Measure it in delivery, not in counts. If routine changes need regression testing across unrelated areas, or if nobody can predict what a change will break, the debt is already expensive.

Should we delete unused fields?

Only after a dependency check, and only when something on the roadmap benefits. Unused fields are usually dormant debt, and dormant debt is the cheapest thing to leave alone.

Is Salesforce Optimizer enough?

It is the right first move, not the last. Optimizer flags platform-level issues but cannot tell you which stand between you and next quarter's roadmap.

Do we have to migrate off Workflow Rules and Process Builder now?

They still run, but passed end of support on 31 December 2025, so defects stay unfixed. Migrate the automations your roadmap touches first, not all at once.

Salesforce and SAP Integration Patterns for Manufacturers

Tekunda Team — Sun, 19 Jul 2026 12:00:00 GMT

Short answer: almost every Salesforce and SAP integration in manufacturing reduces to four patterns: batch synchronization, request and reply, data virtualization, and event streaming. Pick one per data object, and pick on two questions only: which system owns the record, and how stale a copy is allowed to be. The middleware follows from those answers, not the other way round.

We have made this call on order, product and service data for asset-heavy manufacturers. Projects rarely fail because somebody picked the wrong iPaaS. They fail because nobody wrote down who owns the record.

What is a Salesforce and SAP integration pattern?

An integration pattern is the shape of a data flow, independent of the tool that carries it. Salesforce's own architecture guidance names a small set: batch data synchronization, remote process invocation (request and reply, or fire and forget), remote call-in, UI update based on data changes, and data virtualization. Every connector and iPaaS on the market is one of those patterns with a logo on it. Choosing the pattern is architecture. Choosing the product is procurement.

Which SAP data actually has to move for a manufacturer?

Three families cover most of it, and they do not want the same treatment.

Order data. Quotes and opportunities start in Salesforce, but SAP owns the order the moment it is confirmed. Sales needs the confirmed quantity, promised date and status back.
Product, pricing and inventory data. SAP owns the material master, condition records and stock. Salesforce is a consumer here, never an author.
Service and asset data. Ownership genuinely splits. SAP holds serial numbers, bills of material and warranty terms; Salesforce holds the case, the entitlement and the field visit.

Write the owner next to each object before you evaluate a tool. If two systems can write the same field, you have not designed an integration. You have designed a conflict with a schedule.

What are the four patterns worth considering?

Batch synchronization

A scheduled bulk transfer, usually nightly. Right for material master, cost data and historical actuals. Cheap, easy to reason about, easy to replay after a failure. The price is staleness measured in hours, and a nightly window that tightens as volume grows.

Request and reply

Salesforce calls SAP and waits: availability check, credit check, price simulation, order submission. Right when the user needs the truth at that exact second and a cached copy would be worse than a short spinner. The price is that SAP availability becomes CRM availability.

Data virtualization

Salesforce Connect exposes SAP data as external objects over OData 2.0 or 4.0, typically through an SAP gateway, so records are read live and never stored in Salesforce. Right for long-tail reference data people look up but nobody reports on: historical invoices, delivery documents, closed service orders. The price is weak reporting, weak automation and nothing offline.

Event streaming

SAP publishes a change and Salesforce reacts: delivery confirmed, batch released, shipment blocked, asset commissioned. Right for state changes where minutes matter and volume is too high to poll. The price is that you now own ordering, retries and duplicate handling.

How do you choose? Data ownership and latency, not middleware brand

Name the owner per object. One writer, everyone else reads. Put it in the design document, not in someone's head.
Set a latency budget in plain language. "A rep must never promise a date the plant cannot meet" is a budget. "Real time" is a wish.
Count the volume honestly. Peaks, not averages. An event pattern that is comfortable at a thousand messages a day behaves differently at a million a week.
Decide the failure behaviour first. What does a rep see when SAP is down during the quarterly close? Silence is the worst possible answer.

Run those four and the pattern usually picks itself. Most manufacturers end up hybrid: batch for master data, events for order and delivery status, request and reply for the two or three checks that must be live, virtualization for the archive nobody wants to copy.

Where do manufacturers get this wrong?

Syncing everything. Every field copied is a field to reconcile forever. Copy what a Salesforce process actually acts on.
No stable ID map. Matching on customer name or material description works in the demo and fails in production. Carry the SAP key as an external ID.
Order posting that is not idempotent. A retry that creates a second order in SAP is the most expensive bug in this category. Every write needs a correlation key.
No reconciliation job. Drift is a certainty, not a risk. Something has to count both sides and report the delta.
Buying middleware first. The tool then dictates the architecture, which inherits whatever that tool happens to be good at.

Does the middleware brand matter at all?

It matters, second. Salesforce ships MuleSoft Direct integrations for Manufacturing Cloud that keep customer, product and sales order data in sync with SAP. Data 360 offers an SAP HANA connector where batch ingestion is generally available and zero copy federation is still in beta, worth knowing before you plan an analytics layer around it. SAP Integration Suite, Boomi and direct API work remain valid. Each is a pattern in packaged form. Pick the pattern first, then the product that implements it with the least custom code.

The payoff is operational. On a connected-asset programme for ASSA ABLOY we took weekly cases from 3,000 to 350, a 93% reduction across 11,000 devices and up to 2.5 million events per week, with no added support staff. Event volume was routed by pattern, not pushed through one generic sync. Tekunda integrates Salesforce across 70+ enterprise systems, SAP included, as a certified Salesforce SI, ISV and PDO.

FAQ

Should Salesforce or SAP own the sales order?

SAP, from confirmation onward. Salesforce should own the quote and the opportunity and then read order status back, so there is exactly one place where a confirmed order lives.

Is real time integration always better?

No. Real time raises cost, coupling and failure surface. Use it only where a stale value would cause a wrong commitment to a customer, and use batch everywhere else.

Do we need MuleSoft to integrate Salesforce and SAP?

No. MuleSoft is a strong fit for API-led programmes with many consumers, but the same patterns run on SAP Integration Suite, other iPaaS platforms or direct API work.

How long does a Salesforce and SAP integration take?

It depends far more on how many objects you sync than on the tooling. Two or three well-owned objects can go live in weeks; an undecided ownership model can stall a project for a year.

Salesforce for ports and terminal operations: where the TOS ends

Tekunda Team — Sat, 18 Jul 2026 12:00:00 GMT

TL;DR: A terminal operator does not replace its Terminal Operating System with Salesforce. The TOS owns the box: yard, gate, vessel and equipment moves. Salesforce owns everyone who talks to the terminal and everything that happens around the move, which is contracts and tariffs, service requests and claims, equipment as maintained assets, and the portals that shipping lines and hauliers actually log into. Getting that boundary right is the whole design problem.

What does a TOS own, and what does it not?

A Terminal Operating System exists to control the movement and storage of cargo in and around a port or marine terminal. It covers vessel operations, yard management, gate operations, equipment coordination, inventory and the rail and road interfaces. It is the operational system of record and nothing should displace it.

What it was never built for is the commercial and relationship layer around those moves:

The contract, the tariff and the annual renewal with a shipping line or forwarder.
The damage claim, the gate dispute, the demurrage query and the escalation that follows.
The crane as a maintained asset with a warranty, a service history and a spare parts trail.
The lease on a warehouse, a laydown area or a quay slot.
The haulier who wants a slot, an invoice copy and a status, at 03:00, without phoning anyone.

Those are CRM problems wearing operational clothing, and they are where a platform earns its place.

Which terminal workflows actually belong on Salesforce?

Three groups, in the order most operators should adopt them.

Commercial

Shipping line and forwarder accounts, rate cards and tariff negotiation, quotes for ancillary services such as storage, reefer plugs, weighing and inspections, renewals, and property or tenancy management for land and sheds. None of this touches operations, which is exactly why it is the safest place to start.

Service

One queue for gate disputes, damage claims, booking exceptions, documentation chasing and demurrage questions, with real service levels attached. Most terminals run this from shared mailboxes and a phone rota today, which is why nobody can answer how long a claim actually takes.

Equipment and maintenance

Cranes, reach stackers, straddle carriers, reefer points and gate lanes modelled as assets with a real hierarchy, then work orders, preventive maintenance plans, and field scheduling for the crews who do the work. This is asset lifecycle management, and it is where a terminal usually finds the fastest unglamorous savings.

How do vessel and equipment events reach Salesforce without duplicating the TOS?

One rule keeps these programmes out of trouble: the TOS stays the system of record for the move, and Salesforce holds the reference, not the copy.

In practice that means an event-driven integration rather than a nightly table sync. Gate-in and gate-out, vessel arrival and departure, equipment fault codes and reefer alarms arrive as events. Salesforce keeps the identifier, the status and the business context, then deep links back into the TOS for operational detail. Container-level inventory does not belong in CRM objects: it is high volume, it changes constantly, and nobody makes a commercial decision from a stale copy of it.

The same pipe carries the useful automation. An equipment fault event can open a case, triage it against the maintenance history, and create a work order with the right skill and the right part before a supervisor has read the alarm.

What does a portal change for a terminal?

More than most operators expect, because it removes work rather than moving it. A portal for shipping lines, hauliers, tenants and customs brokers can carry slot and appointment requests, invoice and dispute status, document exchange, and damage reports with photos attached at the source.

Ports do run this publicly. A Carahsoft webinar on optimising port communication with Salesforce featured Port Corpus Christi's results, which is a useful signal for anyone who still thinks CRM stops at the quay gate.

How should a terminal phase the programme?

Commercial first. Accounts, contracts, tariffs and pipeline. No operational risk, immediate reporting value.
Then the service queue. Move the shared mailboxes into cases with owners and service levels.
Then equipment. Assets, then work orders, then field scheduling for the maintenance crews.
Then the portal. Only open it once the data behind it is trustworthy, because a portal exposes your data quality to your customers.
Agents last. An AI agent answering "where is my slot" is only safe when the records underneath it are right.

What goes wrong?

Building a second TOS. The moment someone asks for yard planning in Salesforce, stop and redraw the boundary.
Wholesale data sync. Copying container tables into custom objects produces volume, cost and no decisions.
Portal first. It exposes every gap in the data to the people you least want to show them to.
Equipment as custom objects. You lose the standard asset, work order and maintenance model, and rebuild it worse.
Desk-shaped design. Terminals run around the clock, on gates with poor connectivity, on mobile. Design for that or it will not be used.

Where we come in

Tekunda works across logistics and ports and terminals as a certified Salesforce SI, ISV and PDO, including a Gulf terminal operator we deliver for under NDA. The parts that matter here are the ones we already run in production elsewhere: Service Cloud and Field Service for maintenance, Experience Cloud portals, asset lifecycle management, and an integration layer across 70 or more enterprise systems for the TOS, ERP and customs side.

FAQ

Does Salesforce replace a Terminal Operating System?

No. The TOS remains the system of record for cargo, yard, gate and equipment moves. Salesforce carries the commercial, service and maintenance layer around them.

Should container data be synced into Salesforce?

Only the references and statuses that drive a business decision. Full container-level inventory belongs in the TOS with a deep link from the CRM record.

Which Salesforce clouds do terminal operators actually use?

Most commonly Sales Cloud for contracts and tariffs, Service Cloud for claims and disputes, Field Service for equipment maintenance, and Experience Cloud for the customer and haulier portal.

How do equipment faults become work orders?

Fault and alarm events arrive from the equipment or the TOS, open a case, get triaged against maintenance history, and generate a work order with the required skill and parts.

Where should a terminal start if the budget only covers one phase?

The commercial layer. It carries no operational risk, it is quick to prove, and it produces the contract and tariff data every later phase depends on.

Enterprise RAG on Salesforce Data: An Architecture That Holds Up

Tekunda Team — Fri, 17 Jul 2026 12:00:00 GMT

Short answer: retrieval quality decides whether RAG on Salesforce data works, not which model you pick. A frontier model given the wrong three records will answer confidently and wrongly, and swapping the model changes nothing. The three things that actually move the needle are what you treat as a chunk, how permissions are enforced during retrieval, and whether you measure retrieval separately from generation.

Why does RAG on CRM data fail more often than RAG on documents?

Because a CRM corpus breaks the assumptions that document RAG is built on.

Records are short and repetitive. Ten thousand cases about the same product produce near-identical embeddings, so similarity search returns ten variations of one answer.
Meaning lives across objects. The answer to "why did this customer churn" is spread over an account, three opportunities, a contract and a case thread. No single record contains it.
The corpus mutates constantly. Opportunities move stage, cases close, contacts change role. A document corpus is mostly static; a CRM corpus is a moving target with an index behind it.
Access is per user. Two people asking the same question must legitimately get different answers, which is not a scenario most RAG tutorials consider at all.

What is the right chunk when the source is a Salesforce record?

Field-by-field chunking is the most common mistake we are asked to fix. A field value is not a retrievable unit of meaning. Assemble instead.

Chunk at the level of a business event, not a field. For a case, that is subject plus description plus resolution plus the comment thread, rendered as one passage. For an opportunity, the record plus its close reason and key notes.
Denormalize the identifiers a human would use. Account name, product name, serial number, contract number. Embeddings do not resolve foreign keys.
Keep hard metadata alongside the vector. Object type, record id, owner, account, last modified date. Every filter you will ever need at query time has to exist as metadata, not as text.
Keep exact-match retrieval in the loop. Case numbers, SKUs and error codes are precisely where pure vector search is weakest. Salesforce's own hybrid search combines keyword and vector indexes and fuses the ranked results, reporting better performance than either alone (Salesforce Engineering).
Re-embed on change, not on schedule. Tie re-indexing to record change events, or your agent will confidently quote last quarter's status.

How do you make retrieval permission-aware without rebuilding sharing?

This is the requirement that separates an enterprise RAG system from a demo, and it has exactly one safe shape: filter before you retrieve, using the asking user's identity.

Three patterns, in descending order of how well they hold up.

Pre-filtered retrieval. The query carries the user's identity, the retrieval layer restricts candidates to what that user can see, and ranking happens inside that set. Correct, and the only one that survives an audit.
Segmented indexes. One index per audience, such as per region or per business unit. Workable when your access model is coarse and stable, unmanageable when it is not.
Post-filtering. Retrieve broadly, then drop what the user cannot see. Do not do this. Restricted records still consume the top-k slots, so the answer silently degrades, and any ranking signal exposed to the user leaks the existence of the records you filtered out.

Whatever store you use, identity has to propagate all the way through: session, retrieval, prompt, and the audit log. Never ask the language model to enforce access. It is a text predictor, not a policy engine, and a prompt instruction is not a security control.

How do you know whether retrieval is actually good?

Most teams cannot answer this, which is why they keep changing models. Separate the two failure modes: either the right record was not in the context, or it was there and the model ignored it. Only the second is a model problem.

Build a golden set of 100 to 200 real questions from actual users, each labelled with the record ids that genuinely answer it.
Measure retrieval on its own with recall at k and mean reciprocal rank. If the right record is not in the top k, nothing downstream can save you.
Track context precision too. Padding the prompt with near-duplicate chunks costs budget and makes the model hedge.
Run the golden set in CI on every change to chunking, embeddings, ranking or filters, and treat a drop as a build failure.
Only then evaluate answers, with citations back to record ids so a reviewer can check the claim in Salesforce.

Teams that add this harness usually discover their retrieval recall was somewhere around half, and that no model upgrade was ever going to fix it.

What does a stack that holds up look like?

Native or external matters less than the retrieval contract. Data 360 supports vector search and retrievers over unstructured content such as knowledge articles, PDFs and transcripts (Salesforce Help), which keeps grounding close to the data and inside the platform's governance. An external vector store gives more control over chunking, hybrid ranking and cross-system corpora, which matters when the answer also lives in your ERP or your ticketing system.

Pick either, but write the contract down first: what is a chunk, what metadata every chunk carries, how identity is enforced, and what the golden set says good looks like. We build agentic RAG systems on this pattern across Salesforce and 70+ enterprise systems, and it is the contract, not the model, that we spend the most time on. More on how we work is at Tekunda.

FAQ

Does a bigger model fix bad retrieval?

No. If the answering record never enters the context window, model size is irrelevant. Fix recall first, then compare models.

Should I fine-tune instead of doing RAG on CRM data?

Rarely. CRM data changes daily and access is per user, so a fine-tuned model would be both stale and unable to respect sharing. Fine-tuning is for behaviour and format, retrieval is for facts.

How do I stop the agent leaking records a user cannot see?

Filter candidates by the asking user's access before ranking, and log every retrieval with the identity that made it. Prompt instructions are not an access control.

How often should the index be refreshed?

Drive it from record change events rather than a nightly job. In a CRM corpus, a stale index produces answers that are wrong in a way users find hard to detect.

Headless Salesforce and MCP: Running CRM Actions From One Agentic Hub

Tekunda Team — Wed, 15 Jul 2026 12:00:00 GMT

The short answer: headless Salesforce means the platform's data, logic and workflows are callable without the Lightning UI, and an MCP server is the standard way to expose those calls to an AI client. Together they give you one action surface, so an agent, a Slack thread or your own front end can run a CRM action and an ERP action in the same step. Salesforce made this official at TrailblazerDX on 15 April 2026 with Headless 360, and its hosted MCP servers became generally available the same month for Enterprise Edition and above.

What does headless Salesforce actually mean now?

It means the browser is optional. Every capability is reachable as an API, an MCP tool or a CLI command, so the system of record can be driven by something other than a Lightning page. That was the framing at TrailblazerDX 2026, alongside more than 60 new MCP tools and an experience layer that renders components into Slack, Teams, mobile and MCP-compatible clients.

Two clarifications, because both get muddled:

Headless is not UI-less. It means the interface is a choice rather than a dependency. Most headless builds still have a screen. It just is not the org.
Headless is not rip and replace. Your objects, flows, validation rules and sharing model stay exactly where they are. What changes is who is allowed to call them.

What is an MCP server in a Salesforce context?

An MCP server publishes a list of tools an AI client can call, with typed inputs and a permission model behind them. In practice you will meet three kinds:

Salesforce hosted MCP servers, generally available since April 2026 for Enterprise Edition and above, exposing org data, Flows, Apex invocable actions, AuraEnabled methods and named queries.
The Salesforce DX MCP server, aimed at developer workflows such as deploying metadata and running Apex tests.
Your own MCP server, which is where the interesting work sits, because it is the only one that can span Salesforce and everything around it.

The security model is the part worth memorising. The hosted server authenticates per user with OAuth 2.0 and PKCE, and the agent acts inside that user's permissions, with CRUD, field-level security and sharing rules still enforced. An agent is not a superuser.

Why is the value a single action surface, not a nicer UI?

Here is the gap in almost everything written on this topic. Most of it describes Salesforce exposing Salesforce. That is useful, and it is not where the pain is.

Real operational work does not stay inside one system. "Approve this credit exception, release the order and tell the customer" is three systems and one intention. Today that intention is executed by a person tabbing between the CRM, the ERP and a telephony console, translating between them by hand. Every one of those translations is a chance to be wrong.

A single action surface collapses the tab-switching into one callable action:

The agent, or the front end, calls one tool.
The tool orchestrates the CRM write, the ERP call and the notification.
The permission check happens once, somewhere you can audit.
A failure in any leg is one failure, not a half-finished process nobody owns.

A headless implementation that only exposes CRM has moved the buttons. One that exposes intentions has removed the swivel chair.

What does one action hub look like across CRM and the systems around it?

Salesforce stays the system of record. Objects, sharing and validation are untouched.
An MCP layer publishes intentions, not tables. release_order, not update_order_record.
Connectors sit behind each intention: ERP, finance, telephony, scheduling, connected devices. We run this across more than 70 enterprise systems.
One identity model. The caller's permissions decide what the tool will do, in every system it touches.
Clients are interchangeable. Claude, Cursor, Agentforce, a Slack app or your own front end all call the same tools.
Every call is recorded as a business event, not just an API hit.

Tekunda has been building this shape since before it had a product name, and we are the first and only firm delivering headless CRM plus MCP action hubs in production.

What do most teams get wrong?

Publishing objects instead of actions. A tool per object gives an agent a thousand ways to make a mess. A tool per business intention gives it one right way.
Skipping idempotency. Agents retry. If release_order is not idempotent, a retry ships the order twice.
Letting the agent own the permission. Run as the user, not as an integration account that can do everything.
No approval gate on irreversible actions. Read freely. Write with a check on anything financial or customer-facing.
Treating it as an integration project. It is an interface design project that happens to require integration.

Where should you start?

Pick one workflow that already crosses two systems and annoys somebody every week.
Write down the three or four intentions it contains, as verbs.
Implement them as MCP tools, with typed inputs, per-user auth and one audit line each.
Point two different clients at them, an agent and a Slack action for instance, to prove the surface is genuinely shared.
Only then widen the catalogue.

FAQ

Does headless Salesforce mean giving up the Lightning UI?

No. It makes the UI optional. Most implementations keep Lightning for the people who like it and add other entry points for the people who do not.

Is the Salesforce hosted MCP server enough on its own?

It is enough to let an AI client work inside your org. It is not enough for actions that span the org and other systems, which is where a custom MCP layer comes in.

Is an agent with MCP access a security risk?

It carries the risk of the identity it runs as. With per-user OAuth, CRUD, field-level security and sharing rules still apply, so the answer is to scope the user rather than to trust the agent.

Do we need Agentforce to do this?

No. MCP is an open standard, so Claude, Cursor and your own applications can call the same tools. Agentforce is one client among several.

Tekunda builds headless Salesforce implementations and MCP action hubs across CRM, ERP, telephony and connected devices. If your team is tab-switching through a process that ought to be one action, that is the workflow to start with.

Multi-Agent Orchestration on Salesforce: What Makes Agent-to-Agent Handoffs Work in Production

Tekunda Team — Tue, 14 Jul 2026 12:00:00 GMT

The short answer: multi-agent orchestration on Salesforce means one orchestrator agent owns the conversation and hands each task to a specialist agent that owns a narrow domain. What makes it reliable in production is not a bigger prompt on the orchestrator, it is a tight handoff contract between agents: what gets passed, what comes back, and who is allowed to act. Salesforce moved Agentforce multi-agent orchestration to general availability on 15 June 2026, and the Agent2Agent (A2A) protocol extends the same pattern to agents that do not run on Salesforce.

What is multi-agent orchestration on Salesforce?

It is a routing architecture. One primary agent is the user's only point of contact and holds the session context. Behind it sit specialist agents, each scoped to a bounded domain and equipped with its own actions: Apex, Flow, prompt templates, external APIs.

The routing is not a decision tree. The Atlas Reasoning Engine reads every registered agent's description, instructions and available actions, then picks the best fit at runtime. That has a consequence teams underestimate: an agent description is routing logic, not documentation. Vague descriptions produce vague routing.

Why does one big prompt stop working?

Almost every team tries the single-agent version first. It demos well and degrades in production, for reasons that are structural rather than fixable:

Instruction dilution. Rules that matter in one workflow leak into another, and the model averages them.
Tool sprawl. Past roughly a dozen actions, selection accuracy drops and the wrong tool starts firing.
No blast radius. One agent with refund rights has refund rights in every conversation it ever holds.
Untestable changes. A new paragraph about returns can silently change warranty behaviour, and there is nothing to unit test.

A specialist with one job and five actions has none of those problems. The complexity does not vanish. It moves to the seams between agents, which is where it belongs, because a seam can be specified.

What does an orchestrator plus specialists look like in production?

An orchestrator that resolves intent, holds context and escalates. It carries no business actions of its own.
One specialist per bounded domain, for example entitlement checks, field dispatch or billing adjustments, each with its own action set and its own test cases.
A structured context payload passed between them instead of free text.
A human approval gate on anything irreversible or financial.
Tracing on every hop, so a bad outcome is attributable to one agent rather than to "the AI".

Scale is why this matters. In our ASSA ABLOY programme (FocusCura and Phoniro), the operational surface is 11,000 connected devices producing up to 2.5 million events a week across three markets, and weekly cases fell from 3,000 to 350 with no added support staff. Nobody holds an operational load of that shape inside a single prompt.

What makes a handoff between agents reliable?

This is the part vendor material skips, and it is where production systems actually break. Treat every handoff as an interface, not a conversation.

Typed in, typed out. If you cannot write the handoff as a function signature, the orchestrator will invent one, and it will invent a different one tomorrow.
Pass identifiers, not prose. A CaseId and an AssetId survive a handoff. A paraphrased summary does not.
Give the specialist a way to refuse. "I cannot proceed, the entitlement has lapsed" is a routable answer. Silent improvisation is not.
Make actions idempotent. Orchestrators retry. A retry must never issue a second refund.
Version the descriptions. Routing depends on them, so editing one is a production change and belongs in review.

The seam is the product. Agents are the easy part; the contract between them is the engineering.

Where do A2A and MCP actually fit?

A2A handles delegation across platforms. An agent publishes an agent card describing what it can do; a client agent discovers it, delegates a task, and receives messages and artifacts back. That is how an Agentforce orchestrator reaches a specialist running somewhere else entirely.

MCP is the other axis. It gives a single agent access to tools and data. We build MCP servers so one agent can act across the systems a business already runs, instead of forcing every action back through a CRM screen.

Rule of thumb: A2A is agent to agent, MCP is agent to system. Reaching for the wrong one is the most common architecture mistake we see.

How do you roll this out without breaking the seams?

Start with three agents on one workflow that already has clean data. Agents layered over messy data multiply the mess.
Instrument before you scale. If you cannot trace a single hop today, you will not debug ten agents next quarter.
Give every specialist a named human owner.
Test routing adversarially, with ambiguous and multi-intent requests, not with the happy path.
Keep a kill switch per specialist, so one bad agent does not take the whole workflow down.

FAQ

Is multi-agent orchestration available in production on Salesforce today?

Yes. Salesforce moved Agentforce multi-agent orchestration to general availability on 15 June 2026, with A2A support for agents outside the platform.

How many specialist agents should we start with?

Three, on one workflow. Prove the handoffs and the tracing first, then add domains one at a time.

Does a bigger model remove the need for orchestration?

No. A stronger model improves reasoning inside an agent. It does not give you scoped permissions, per-domain tests or an attributable failure. Those come from the architecture.

What breaks most often in production?

Handoffs. Context lost between agents, misrouting caused by a vague agent description, and retries that repeat an action which was never idempotent.

Do we have to rebuild agents that live on other platforms?

No. A2A lets an Agentforce orchestrator delegate to third-party agents, so a non-Salesforce specialist can join the same workflow.

Tekunda builds multi-agent systems on Salesforce and off it. It was first to run agent-to-agent orchestration and SWARM architecture in production, and still does. If you are moving from one agent to a team of them, designing the seams is the work worth doing first.

How to reduce Salesforce license and platform costs: audit the drift, not the contract

Tekunda Team — Mon, 13 Jul 2026 12:00:00 GMT

Short answer: Most Salesforce overspend is not the result of a bad negotiation. It is drift: people who left, licenses that no longer match what anyone actually does, add-ons bought for a project that finished, and data nobody ever deleted. An honest audit of activity, license mix, feature licenses, add-ons and storage usually finds more money than the renewal conversation will.

Why do most orgs overpay for Salesforce?

Because the org changes every week and the contract changes once a year. Every offboarding, role change, cancelled project and abandoned integration leaves a paid artefact behind, and removing it is nobody's job. Zylo's 2026 SaaS Management Index puts average license utilisation at 54%, with $19.8M in wasted spend annually per organisation across the SaaS estate (Zylo).

Drift also compounds. Salesforce announced an average 6% list price increase effective 1 August 2025 across Enterprise and Unlimited editions of Sales Cloud, Service Cloud, Field Service and selected Industry Clouds, with no change to Foundations, Starter and Pro editions (Salesforce). Every seat you are not using gets slightly more expensive to not use.

Where does the money actually leak?

Inactive and departed users

Start with last login. Anyone with no login in 90 days is either gone, on the wrong license, or was never onboarded. One detail matters here: freezing a user blocks the login but keeps consuming the license. Only deactivating releases it for reassignment.

A license mix nobody revisited

Most orgs buy one edition for everyone at go-live and never revisit it. Three years later, warehouse staff, finance approvers and read-only managers are all on the same full CRM seat as the sales team.

Feature and permission set licenses

Some are free, some are paid, and the paid ones tend to get assigned in bulk during a rollout and never reviewed again. Pull the assignment counts and compare them against who has used the feature this quarter.

Add-ons that outlived their project

Managed packages, industry add-ons and AppExchange subscriptions bought for a specific initiative. If nobody can name the business process an add-on serves today, it is a candidate for removal.

Storage and data volume

File and data storage grows quietly: old attachments, orphaned records, a recycle bin nobody empties, and integration logs written to a custom object with no retention rule. Data volume is a real cost line, not a rounding error.

Integration users and sandboxes

Integration accounts often sit on a full CRM license because that is what was available on the day. Check what your edition entitles you to before renewing another one. The same goes for sandboxes that were spun up for a migration and never refreshed or removed.

How do you run a license audit in a week?

Export every user with last login, license type, profile and role. Flag anyone with no login in 90 days.
Split that list into leavers and occasional users. Leavers get deactivated, which returns the license to the pool.
Map the remaining users to what they actually open. Object usage tells you more than a job title does.
List every paid add-on with a named owner. No owner, no business process, no renewal.
Check storage consumption against your entitlement and identify the top consumers.
Total the findings and take them into the renewal, not after it. The numbers are only leverage if they exist before the conversation starts.

When does switching to a cheaper license type make sense?

When the user genuinely lives in custom objects rather than in the standard CRM. Platform licenses keep Accounts, Contacts, custom objects, reports and dashboards, but they do not give access to Leads, Opportunities, Cases or Campaigns, and Entitlements, Orders and Price Books are out too. Salesforce Ben's worked example puts a Platform seat at $25 per user per month against $165 for Enterprise (Salesforce Ben).

The discipline is simple: before you move anyone, list the objects and features they touched over a full quarter. A migration that saves a licence fee and then breaks a service agent's case queue costs more than it saved.

What should you not cut?

The sandbox you actually deploy through. Saving that line item means testing in production.
Backup and recovery. The cheapest possible org is the one that cannot be restored.
Audit and security capabilities you are relying on for a compliance obligation.
The admin capacity that runs the audit. Cut that and you are back here in eighteen months.

How do you keep the drift from coming back?

Put deactivation in the offboarding checklist, not in someone's memory.
Give every paid add-on a named owner and a review date.
Re-run the activity export quarterly. It takes an hour once the query exists.
Attach a retention rule to any object an integration writes to.

We do this pass at Tekunda before designing anything new on a client org, for a plain reason: a smaller, cleaner org is cheaper to run and faster to change.

FAQ

Does deactivating a user free up the license?

Yes. Deactivating releases the license for reassignment. Freezing only blocks the login and keeps the license consumed, which is why frozen users are a common hidden cost.

Can we reduce our license count in the middle of a contract?

Usually not. Most subscriptions are committed for the term, so the practical move is to reassign freed licenses instead of buying more, and to right-size at renewal.

How much can a license audit realistically recover?

It depends on how long the org has run unattended. With average utilisation at 54% across SaaS estates, an org that has never audited should expect to find unused seats, unassigned add-ons and storage it is paying to keep.

Is a Platform license always the cheaper option?

Only when the user does not need the standard CRM objects. Check real object usage over a quarter before moving anyone, because the objects Platform excludes are the ones service and sales teams live in.

When should we start preparing for renewal?

Early enough that the usage data already exists when the conversation opens, and early enough to deactivate and reassign rather than simply accept the quote.

When to Build a Custom Salesforce App Instead of Configuring

Tekunda Team — Sun, 12 Jul 2026 12:00:00 GMT

Short answer: configure first, every time. Build custom when the logic is a genuine differentiator, when it must run outside a single record's lifecycle, or when you are rebuilding the same workaround for the third time. The trigger for building is not complexity, it is repetition and ownership: complexity you configure once is fine, complexity you re-explain every quarter is not.

What is the difference between configuring, extending and building?

Configure: standard objects, page layouts, validation rules, Flow. No deployable code, and it upgrades with the platform.
Extend: custom objects and fields plus a little Apex or a Lightning Web Component around a mostly standard process. Still Salesforce-shaped.
Build: a designed application. Its own data model, services, tests and release cycle, whether that ships as Apex and LWC in your org or as a packaged product.

Most arguments about "build versus configure" are really arguments about the middle one, where the honest answer is usually to extend rather than to start a project.

Why is configure-first still the right default?

Salesforce's own guidance has been consistent for a decade: evaluate the native and declarative features before you write code. Declarative work carries no test code, no repository and no upgrade tax, and it moves forward automatically with each release. The limits also behave differently. Declarative work runs into design limits, such as how many rules you can put on an object, while code runs into execution governor limits like SOQL query counts, which are much harder to design around (Salesforce Developers).

The floor also keeps rising. Workflow Rules and Process Builder are no longer supported after 31 December 2025, new ones cannot be created, and Salesforce points teams at the Migrate to Flow tool (Salesforce Ben). Anything you build today competes with what the platform will absorb tomorrow, which is an argument for building less, not for building nothing.

Where does configuration stop paying off?

These are the five trip-wires we use. One of them is a conversation. Two or more is a decision.

The flow has become a program. If nobody can predict the outcome by reading it, and a change needs a careful afternoon, you already have software. You just have it in a format with no tests, no code review and no diff worth reading.
The requirement is a data model, not a screen. Reporting that needs three unrelated objects joined, or a hierarchy the standard model cannot express, is a design problem. Configuration will produce a shape you have to work around forever.
The behaviour lives outside one record's lifecycle. Scheduled work, high-volume event ingestion, cross-system reconciliation, retry and idempotency. Declarative automation is triggered by records; these things are not.
The logic is your competitive difference and it changes often. Pricing rules, routing intelligence, entitlement logic. Anything where being 10% better than a competitor matters deserves tests, versioning and an owner.
You are paying for it three times. The same workaround rebuilt in a second country, a second business unit, a third client org. That is not configuration any more, it is an unpackaged product.

How do you compare the real cost honestly?

Not build cost against configuration cost. Compare three years of ownership on both sides.

Configuration carries: admin time per change, regression risk nobody measures, onboarding cost for each new admin who has to learn the workaround, and a cap on what you can ever automate.
Custom carries: initial engineering, test coverage, code review, an upgrade path across three releases a year, and the risk that the platform ships your feature for free next year.

The comparison usually turns on one number that nobody writes down: how many times per year the process changes. Frequent change favours code with tests, because tests are how you change something safely. Rare change favours configuration, because nobody has to maintain the muscle.

What does "build" actually mean now?

Rarely a from-scratch application. In practice it is one of four shapes: Apex and Lightning Web Components inside the org; a packaged component you install into several orgs; a managed package on the AppExchange; or a service outside Salesforce that the org calls through an API or an MCP server, with an agent action in front of it.

The packaged options matter more than teams expect. Building as a package forces the versioning, the upgrade path and the isolation you would otherwise skip, and it makes the second and third deployment nearly free. This is the discipline we brought from product work into implementation: because Tekunda builds and ships AppExchange products as a PDO, our implementation work inherits reusable, tested components rather than rebuilding each one.

How do you keep a custom build from becoming the next mess?

Give it an owner and a deprecation plan on day one. Code without an owner becomes configuration nobody can read.
Keep configuration values in custom metadata, not in the code. The whole point is that the business can change them without you.
Write the tests as the specification, not as a coverage tax.
Re-check each release whether the platform has caught up. Deleting your own code is a legitimate result.

Done well, the payoff is not an elegant architecture, it is operational. For ASSA ABLOY we took weekly cases from 3,000 to 350, a 93% reduction across 11,000 connected devices and up to 2.5 million events a week, in three markets and with no added support staff. That volume was never going to be a Flow. If you are weighing the same decision, talk to us before the build, not during the rescue.

FAQ

Is custom code always more expensive than configuration?

No. It is more expensive to start and often cheaper to change. Compare three years of ownership, including the admin hours and regression risk configuration quietly consumes.

How complex is too complex for Flow?

Use a human test rather than an element count: if a competent admin cannot predict what it does by reading it, or cannot change it safely in an hour, it has become software.

Should we build it or buy it from the AppExchange?

Buy when the capability is a commodity and a listed app covers most of the requirement. Build when the logic is the reason customers choose you.

Does going custom lock us out of platform upgrades?

Not if it is built as a package with a version and a test suite. What blocks upgrades is undocumented code with no owner, and that happens to configuration too.

AppExchange Security Review for Agentic Apps: What Is Different

Tekunda Team — Sat, 11 Jul 2026 12:00:00 GMT

Short answer: agentic apps go through the same AppExchange security review as any other managed package. What changes is the surface it covers. Salesforce scopes its testing by following the data, and in an LLM-backed app customer data now travels into a prompt, often out to a model, and back as text that can trigger an action. Prepare three answers before you submit: what goes into the prompt, what leaves the org, and what the agent is allowed to do on a user's behalf.

What actually changes when your package is agentic?

An agentic app, for review purposes, is any package that ships agent actions, topics or prompt templates, or that calls a language model from Apex or Flow. The review guidelines have not been rewritten around it (Salesforce Developers). The scope has simply grown, because Salesforce determines what to test with a follow-the-data approach, and there is far more data movement to follow than in a classic CRM package.

In a classic managed package the risky paths were finite: SOQL, sharing, a couple of callouts, some Visualforce output. In an agentic app the same package also constructs prompts from customer records, sends them somewhere, and then acts on the answer. Every one of those hops is a place a reviewer will look.

What do reviewers ask about prompt handling?

Be ready to show, in the Developer Edition org you submit, exactly where prompt text comes from and what constrains it. In practice that means five things:

Instruction integrity. User-supplied text must not be able to rewrite your system instructions. Treat every free-text field that reaches a prompt as hostile input.
Grounding respects permissions. Records used to ground a prompt must be read in the running user's context, with sharing and field-level security enforced. An agent that can summarise a record the user cannot open is a sharing violation with better manners.
Model output is untrusted. Never render it raw into markup and never concatenate it into a query. The old injection rules apply to generated text too.
Least data in the prompt. Send the fields the task needs, not the record.
Log discipline. If you store prompts or completions for debugging, you are storing customer data. Say so, scope it, and let admins turn it off.

What has to be true about data egress?

This is the question classic packages rarely had to answer well, and it is where agentic submissions lose weeks. If any component sits outside Salesforce, the submission requires the URLs and login credentials for those external components, a Checkmarx scan report and a dynamic application security test report (Salesforce Developers). Add to that, from experience, what your reviewer will want spelled out:

An explicit list of which objects and fields can leave the org, per feature.
A named credential for every model endpoint, so the endpoint and its authentication never sit inside Apex (Salesforce Help).
Who holds the credential: the subscriber's own key, or yours on their behalf. Say which, and why.
What the model provider retains, for how long, and in which region.
Whether an admin can switch the external call off and keep a working app.

What about calls to third-party models?

Where you place the trust boundary decides how much of the review lands on you. Use the platform's own AI services and the boundary is largely Salesforce's. Call an external model directly from your package and it is entirely yours to evidence: the endpoint, the authentication, the failure behaviour when the provider is down or returns garbage, and the tenant isolation between subscribers. Give reviewers working test access to that external component, not a description of it.

What is the agent allowed to do on a user's behalf?

The moment an action writes, deletes, sends or pays, the review stops being about code and starts being about authority. Grant the narrowest permission set the action needs, run in user context, require a human confirmation for anything irreversible, and write an audit record of what the agent did and on whose behalf. Salesforce framed the standard plainly when it opened its agent marketplace to partners:

You need to be able to trust the AI. That means we need to understand permissions and respect guardrails, and our enterprise customers need to stay compliant with their solutions. (Alice Steinglass, EVP and GM, Salesforce Platform, diginomica)

What should you prepare before you submit?

A managed and released package. Unmanaged and beta packages are rejected.
A Developer Edition org with the solution installed, clean sample data, credentials and usage instructions.
Documentation of any false positives in your scan results.
Scan reports and credentials for every external component, including your model gateway.
A one-page data-flow description per AI feature: trigger, fields sent, destination, retention, and the admin switch.

The first four are the documented submission materials. The fifth is not, and it is the one that turns a multi-round review into a single pass.

Is AgentExchange a different review?

AgentExchange opened at TDX 2025 with more than 200 partners publishing four component types: actions, prompt templates, topics and agent templates, all of which Salesforce says passed security review (diginomica). Treat it as the same trust bar applied to smaller units. A single action carries the same three questions as a full app, with less code to hide behind.

Tekunda is a Salesforce PDO, and we have taken packages through security review in healthcare, logistics and manufacturing, including the Syntilio managed package, which cleared review and shipped to the AppExchange. If you are packaging an agentic app, talk to us before your first submission rather than after your first rejection.

FAQ

Does an AI feature require a separate security review?

No. It is reviewed with your package, but it widens the scope, because the data path now leaves the objects and travels through a prompt.

Can I ship my own model API key inside the package?

You can architect it either way, but be explicit about which you chose. A shared key makes tenant isolation and per-subscriber consent your responsibility to prove.

Do I need to enforce sharing on data used for grounding?

Yes. Grounding is a read. The usual sharing and field-level security rules apply, and a summary that leaks a hidden field fails the same way a raw query would.

What is the most common reason an agentic submission comes back?

Undocumented egress. The code is often fine; what is missing is a clear statement of which customer data leaves the org, where it goes and how long it stays there.

How ISVs Pass the Salesforce AppExchange Security Review

Tekunda Team — Wed, 08 Jul 2026 12:00:00 GMT

Most AppExchange security review rejections are not exotic bugs. They trace back to a short, predictable list: unenforced CRUD/FLS, sharing violations, weak session settings, and secrets in metadata. ISVs that treat the review as a code audit two weeks before submission usually lose a full cycle to it.

Why do apps fail the Salesforce security review?

Salesforce's review team runs static analysis (Checkmarx, PMD via Salesforce Code Analyzer). Since the hosted Chimera scanner retired on 2025-06-16, the dynamic scan against any third-party endpoints your package calls is yours to run and submit, as covered in Running Your Own Dynamic Scans After Chimera. The failures we see most on ISV engagements fall into four buckets:

CRUD/FLS gaps. Apex that reads or writes objects without checking the running user's object and field-level access, especially in Visualforce controllers and REST endpoints.
Missing sharing declarations. Classes without with sharing that perform DML, or a "with sharing" class that calls a "without sharing" helper and inherits its looser context.
Session and identity misconfiguration. Test orgs with identity challenge or MFA blocking the reviewer's tooling, instead of the recommended IP allowlist approach.
Secrets in the wrong place. API keys stored in custom metadata types any subscriber admin can query, and PII logged through System.debug.

How do you prepare an app for the AppExchange security review?

Preparation is mostly discipline, not new tooling. Before you request a review:

Run Salesforce Code Analyzer against the full package, not just recently touched classes, and triage every finding.
Confirm every DML statement sits inside a class declared with sharing, or document the specific case for bypassing CRUD/FLS (roll-up aggregates and internal logging objects are the two Salesforce generally accepts).
Scan every non-Salesforce domain your package calls with an approved web application scanner and resolve high-severity findings before submission.
Move secrets out of metadata and into Named Credentials or an external secret store referenced at runtime.

What does a false positive from Checkmarx or PMD actually mean?

Scanners flag patterns, not intent, so a chunk of every report is noise: a SOQL query that merely looks like string concatenation, or a debug line that never touches user data. Treating every flagged line as a required code change wastes a cycle. The faster path is triaging each finding against real risk, fixing what's genuinely exploitable, and writing a short justification for anything left as-is. Reviewers read justifications; they don't reward blanket "fixed" claims that don't hold up on re-scan.

How does an implementation partner reduce security review risk?

A partner who has taken packages through the review before knows which findings are worth arguing and which are worth just fixing, and that judgment is where the time savings come from. Tekunda has led AppExchange security reviews end to end for ISV clients, from the initial Apex and integration audit through resubmission after reviewer feedback, so the two or three round trips that catch first-time submitters off guard rarely happen on our engagements.

Integration surface compounds review scope fast: every callout, remote site setting, and domain that stores Salesforce data is in scope for the reviewer's web application scan. Getting that right the first time, through our integration engineering work, is usually the difference between a clean submission and a second round of findings.

What happens if the review comes back with findings?

A rejection is not a restart. If findings only touch code running on the Salesforce platform, upload a new managed package version and start review again from the Packages tab. If the fix was entirely in your external application, you can usually edit the existing submission instead. Either way, log a case against "Partner Community & AppExchange" with your package name, ID, and version so the review team matches your resubmission to the right queue.

FAQ

How long does the Salesforce security review take?

Timelines vary by submission complexity and current review volume, and Salesforce does not publish a fixed SLA, so plan release calendars with buffer.

Can an ISV skip the review for a narrow-audience package?

No. Any managed package, Platform API solution, or Marketing Cloud API solution distributed on AppExchange must pass review before listing, regardless of intended audience size.

Does the review apply to unmanaged packages?

The formal security review process applies specifically to managed 2GP and 1GP packages and API-based solutions submitted for AppExchange listing.

What's the single most common CRUD/FLS mistake?

Building a controller or REST endpoint that reads or writes an object directly via SOQL/DML without checking the running user's permissions first, silently bypassing profile and permission set restrictions.

Getting a package through review cleanly is one part of shipping on AppExchange; building the product and integrations right the first time is the harder part. If you're preparing a submission or planning your next release, talk to our product engineering team, or get in touch to scope the work.

How Salesforce CLI Turns Admin Work Into Repeatable Code

Tekunda Team — Wed, 08 Jul 2026 12:00:00 GMT

The Salesforce CLI (sf) matters because it moves the source of truth for your org out of clicks in Setup and into files a team can read, review, and script. That single shift is what separates a solution that happens to work from one that stays maintainable as the team and the org grow.

Most orgs drift because changes live only in the click-trail of whoever made them. A permission set gets edited by hand, a validation rule gets tweaked, and six months later nobody remembers why. The CLI does not fix people; it fixes the record. Every command it runs operates on metadata files in your project directory, so every change is diffable, reviewable, and reversible, the same way application code already is.

What does source-driven development actually change?

Source-driven development means your local files, not the org, are authoritative. You retrieve metadata with sf project retrieve start, edit it in an IDE with real syntax checking, and push it back with sf project deploy start. The org becomes a target you deploy to, not a place where configuration quietly accumulates. For a product-engineering team, this is the difference between debugging "what changed" by asking around and debugging it by reading a commit.

How do scratch orgs reduce risk in a build?

A scratch org is a full, disposable Salesforce environment defined by a JSON file and spun up with one command. Because it is disposable, engineers stop being precious about testing in it. Create a scratch org, push a feature branch into it, run the destructive test case you were nervous about, then delete it, with zero risk to any shared sandbox. Teams that adopt this habit catch more edge cases before code reaches a shared environment, because thorough testing costs almost nothing.

A typical loop looks like this

Create a scratch org from a definition file scoped to the feature you are building
Push source and load a small, representative data set
Run Apex tests and manual checks against that isolated org
Delete the scratch org once the branch merges

Can the CLI replace manual admin work?

A surprising amount of it, yes. Anything you do repeatedly by hand in Setup is a candidate for a script built on sf commands: reassigning permission sets after a release, loading a consistent test data set with sf data import tree, or auditing which profiles have a given field-level security setting. Scripting these tasks does two things a manual process cannot: it makes the step identical every time, and it makes the step something a junior engineer can run safely without tribal knowledge.

This is especially valuable on solutions with real complexity underneath, like custom integration logic or a managed package with a namespace to protect. Namespaced scratch orgs let you validate packaging behavior in an environment that actually resembles production, rather than finding out about namespace collisions after a release.

What do sf plugins add to the toolchain?

The CLI is plugin-extensible, so teams are not limited to the built-in command set. Plugins exist for static code analysis, dependency graphing between packages, and bulk data operations that would otherwise mean writing one-off scripts by hand. A well-maintained plugin is usually faster and more reliable than building the equivalent tooling in-house, and it keeps the workflow inside the same command-line habit your engineers already have.

None of this is about running a pipeline for its own sake. It is about giving a team the same engineering discipline on Salesforce that they would expect on any other platform: reviewable changes, repeatable environments, and less time re-discovering how the org actually works. If your team is building something on Salesforce that needs to hold up under real usage, that discipline is worth investing in early. Our product development team builds this way by default; reach out if your process has more friction than it should.

FAQ

Do I need DevOps experience to use the Salesforce CLI?

No. The core commands, like creating a scratch org or deploying source, are approachable for any developer or technical admin willing to work from the command line.

Is a scratch org the same as a sandbox?

No. Scratch orgs are temporary and defined by a config file, typically lasting days, while sandboxes are longer-lived copies of production used for staging and QA.

Can the Salesforce CLI manage both code and configuration?

Yes. It retrieves and deploys any metadata type, including Apex, Lightning components, flows, permission sets, and object definitions, not just code.

What is the fastest way to start using it well?

Pick one repetitive manual task, like permission set assignment after a release, and script it first. Small, real wins build the habit faster than a full workflow overhaul.

Salesforce Integration Architecture: Patterns That Actually Scale

Tekunda Team — Wed, 08 Jul 2026 12:00:00 GMT

The integration pattern you choose, not the tool, decides whether Salesforce data stays clean or turns into a synchronization mess. Point-to-point connections are fast to build and fast to break; middleware and event-driven patterns cost more upfront but survive the third, fourth, and tenth system you connect. Most integration pain traces back to that early architecture decision, not to Salesforce itself.

Why do most Salesforce integrations break down?

Two systems rarely share the same data model. Salesforce thinks in Accounts, Contacts, and Opportunities; an ERP thinks in customer master records and sales orders. Every integration has to reconcile those shapes, and teams that skip this step end up bolting fields onto Salesforce objects to mirror whatever the other system sends. Six months later nobody remembers why Custom_ERP_ID__c exists or what happens if it's blank.

The fix isn't a tool, it's a canonical data model: decide what an "Account" means across your systems before you write a single integration flow, and build transformation logic around that definition instead of letting the last-connected system dictate the schema.

Point-to-point or middleware: which pattern fits?

Point-to-point integrations, a direct API call from Salesforce to System B, make sense for one or two connections with simple, stable data. Once you're integrating three or more systems, point-to-point becomes an unmaintainable web: every new connection multiplies the number of places a field mapping can drift out of sync.

A middleware or ESB layer, such as MuleSoft, Boomi, or a lighter custom message broker, centralizes transformation and routing so Salesforce talks to one integration layer instead of five downstream systems directly. That's a real infrastructure investment, so it's worth reserving for integration landscapes that are actually growing, not a single one-off sync.

How do you handle real-time vs batch data?

Not everything needs to sync instantly, and treating every integration as real-time is how teams burn through Salesforce API limits for no benefit. A useful rule of thumb:

Use Platform Events or Change Data Capture for anything a user needs to see reflected immediately, like order status or support case updates.
Use scheduled batch jobs and the Bulk API for large, non-urgent volumes, like nightly financial reconciliation.
Avoid polling loops that hit the REST API on a timer just because it's easier to build. They waste API calls and add latency compared to event-driven alternatives.

Change Data Capture is underused: it publishes field-level change events for standard and custom objects without you having to build custom triggers to detect what changed.

How do you prevent duplicate records and failed syncs?

Every integration eventually retries a request, whether from a timeout or a queued job that runs twice. If your integration isn't idempotent, that retry creates a duplicate Opportunity or double-counts a metric. The fix is a stable external ID field on the Salesforce object, paired with upsert calls keyed to that ID instead of blind create calls.

Error handling deserves the same rigor as the happy path. Failed records should land in a dead-letter queue or error log with enough context to reprocess them, not silently vanish because a single record in a 200-record batch failed validation.

MuleSoft or a custom-built integration layer?

MuleSoft earns its cost with many systems, a dedicated integration team, and connectors that map closely to what you're building. A custom-built layer using Apex, a message queue, and a lightweight orchestration service is often cheaper to ship for a handful of well-defined integrations through dedicated development work, but it puts long-term maintenance on your own engineering team.

It's a build-versus-buy tradeoff that depends on integration count and how fast your system landscape is growing. That decision is worth getting outside eyes on before you commit, which is where Tekunda's integration services come in: we help teams pick and implement the pattern that fits their actual roadmap, not the one a vendor demo made look easy.

FAQ

What's the difference between Platform Events and Change Data Capture?

Platform Events are custom-defined messages you publish explicitly from Apex or a flow, while Change Data Capture automatically emits events when standard or custom object records change, with no custom publishing logic required.

Do I need MuleSoft to integrate Salesforce with other systems?

No. MuleSoft is one option among several, including Boomi, Informatica, or a custom-built middleware layer; the right choice depends on how many systems you're connecting and who will maintain the integration long-term.

How do I avoid hitting Salesforce API limits?

Batch large data volumes through the Bulk API instead of single-record REST calls, use Platform Events or Change Data Capture instead of polling, and combine related calls where the API supports composite requests.

What's the safest way to authenticate a third-party integration with Salesforce?

Use a Connected App with OAuth 2.0, scope the permissions to only what the integration needs, and rotate credentials on a schedule rather than relying on a single long-lived token.

Salesforce Metadata Governance for Growing Orgs and Teams

Tekunda Team — Wed, 08 Jul 2026 12:00:00 GMT

Salesforce metadata governance means treating every custom object, field, flow, and permission set your team creates as a long-lived asset rather than a one-off fix. That requires consistent naming conventions, metadata tracked in source control, and clear ownership before anything reaches production. Orgs that skip this discipline accumulate config sprawl that turns a two-hour ticket into a two-week investigation.

What does "metadata" actually cover in a growing org?

Metadata is everything that defines how your org behaves outside the raw records: custom objects and fields, page layouts, validation rules, permission sets, Flows, and Apex classes. Two of those categories matter more than people think as a team grows.

Declarative metadata - Flows, validation rules, layouts, and approval processes built through Setup. Anyone with admin access can create it, which is exactly why it needs a review process.
Programmatic metadata - Apex, Lightning Web Components, and triggers. Changes go through a developer and, ideally, a code review, but they can still collide with declarative automation on the same object.

The line blurs fast once a Flow calls an invocable Apex method or a trigger fires alongside a Flow on the same record. Governance means deciding, in advance, who owns changes on each object.

How do naming conventions prevent config sprawl?

Config sprawl usually starts with a field called Status_2__c because nobody could tell if Status__c was still in use. A simple convention fixes this before it happens: prefix custom fields and Flows with the team or domain that owns them (SVC_ for service, SLS_ for sales), and require a description on every field explaining what created it and why.

The payoff is not cosmetic. When a new hire or an outside consultant opens Setup six months later, naming conventions are the difference between understanding the org in an afternoon and reverse-engineering it for a week.

Why does metadata belong in source control, not just Setup?

Changes made directly in Setup leave no diff, no reviewer, and no rollback path. Pulling metadata into a Git repository with Salesforce DX changes that: every field, Flow, or permission set edit becomes a pull request someone reviews before it ships, and every production incident has a commit history to trace back to.

This matters most for teams running multiple sandboxes. Without source control, two people editing the same Flow in different sandboxes is how conflicting logic ends up live at once.

How do you document dependencies before they break something?

The most common outage in a mature org is not a bad deploy, it is a field or Flow someone deleted without realizing an integration or a report depended on it. Before deprecating any metadata component, check its dependency tree in Setup ("Where is this used?") and confirm nothing downstream, including middleware and scheduled jobs, still reads it.

Write that dependency down somewhere durable, not in a Slack thread. A short note in the field description or a shared runbook, such as "used by the invoicing integration, do not delete," saves the next person from rediscovering it the hard way.

What keeps metadata debt from creeping back in?

Governance is not a one-time cleanup, it is a recurring habit: a quarterly audit of unused fields and inactive Flows, a rule that new automation gets a named owner, and a lightweight review gate before anything merges to production. Teams that treat this as ongoing maintenance are the ones whose orgs stay fast to change years later, instead of becoming something everyone is afraid to touch.

If nobody on your team is fully sure what half the Flows do anymore, that is usually a sign the underlying architecture needs a second look, not just a cleanup pass. Tekunda's product development team helps growing companies rebuild that structure without a rip-and-replace, and our AI agent tooling can surface unused fields and orphaned automation faster than a manual audit. See our blog for more on our approach, or get in touch to talk through your org.

FAQ

What is Salesforce metadata governance?

It is the set of conventions, ownership rules, and version-control practices that keep custom objects, fields, and automation organized and auditable as an org grows.

Should Flows or Apex own a given piece of automation?

Simple record-level logic is usually fine as a Flow owned by admins; anything requiring bulk-safe processing, complex branching, or external callouts is better as reviewed Apex owned by developers.

Do small teams need metadata source control?

Yes. Even a two-person admin team benefits from a commit history and rollback path the moment a bad Flow change reaches production during business hours.

How often should we audit unused metadata?

Quarterly is a reasonable baseline for most active orgs; teams shipping weekly releases often fold a lighter dependency check into every deploy instead.

Salesforce Packaging Models for ISVs: 1GP vs 2GP vs Unmanaged

Tekunda Team — Wed, 08 Jul 2026 12:00:00 GMT

For an ISV building a commercial AppExchange product, the packaging model is a one-way door: your namespace, your upgrade path, and your IP protection are all set by this one early decision. Second-Generation managed packages (2GP) are the right default for almost every new commercial product today, with First-Generation (1GP) reserved for legacy edge cases and unmanaged packages ruled out entirely for anything you plan to sell.

What's the difference between 1GP, 2GP, and unmanaged packages?

An unmanaged package has no namespace and ships fully editable metadata. It's fine for open-source templates or a one-time deployment, but every component becomes indistinguishable from the customer's own customizations the moment it lands - you lose the ability to identify, support, or safely upgrade what you built.

A managed package, whether 1GP or 2GP, is namespaced and locked. Customers install it, use it, and cannot edit its internals directly. That's what makes it a product rather than a one-off deployment: you control the release cadence, and Salesforce enforces the boundary for you.

The 1GP vs 2GP split is about tooling and org dependency. 1GP packages are built and versioned inside a dedicated packaging org that becomes a permanent, irreplaceable part of your release pipeline. 2GP packages are source-driven, built from version control with the Salesforce CLI, and don't require a standing packaging org at all - which is why Salesforce has been steering new ISVs toward 2GP for years.

Why is your namespace a permanent decision?

Once a namespace is registered against a Developer Edition org and used in a released package, it cannot be renamed, transferred to a different org, or reused. Every Apex class, custom field, and object your product ever ships will carry that prefix in every customer org, forever. Typos, awkward abbreviations, and rushed naming choices don't get a do-over - plan the namespace like a product name, not a technical afterthought.

How do IP protection and licensing actually work?

Managed packages compile Apex into byte code that customers can't view or edit, which is the baseline IP protection any commercial product needs before it goes near the AppExchange Security Review. Unmanaged packages offer none of that - your business logic ships as plain, readable, forkable metadata.

Licensing is a separate layer entirely. To actually meter seats, trials, and expirations, you connect your package to a License Management App (LMA), which tracks installs against your leads and opportunities. This only works cleanly with managed packages - there's no reliable way to license and enforce entitlements on something a customer can freely edit.

What about unlocked packages?

Unlocked packages sit between these worlds: namespaced and version-controlled like 2GP, but with editable metadata and no licensing enforcement. They're built for internal, multi-org deployment inside a single company, not for selling to strangers on the AppExchange. Don't reach for them as a shortcut around commercial packaging.

Which packaging model fits your ISV stage?

Building a new AppExchange product today: use 2GP. CLI-driven versioning, ancestry tracking for upgrades, and no dependency on a fragile packaging org.
Inheriting or maintaining an older 1GP product: stay on 1GP until there's a deliberate migration plan - namespace and subscriber base carry across, but the conversion has real technical constraints.
Distributing free, editable tooling or templates: unmanaged is legitimate here, precisely because you're not protecting IP or charging for upgrades.
Standardizing deployments across your own orgs: unlocked packages, not managed packages built for resale.

Getting this wrong is expensive to unwind - Tekunda's product development work with AppExchange partners starts with exactly this decision, before a single component gets built, because every governance, testing, and release choice downstream depends on it.

FAQ

Can I switch from unmanaged to managed later?

Not directly. You'd rebuild the components inside a namespaced managed package and manage a real customer migration, since the underlying metadata and IDs don't carry over cleanly.

Can I convert a 1GP package to 2GP?

Yes, Salesforce supports converting 1GP managed packages to 2GP while keeping the same namespace and subscriber orgs, though it requires careful planning around package ancestry and existing installs.

Do I need a namespace if I'm not selling on the AppExchange?

Only if you're distributing a managed or unlocked package across multiple orgs. A single internal deployment via unmanaged metadata or change sets doesn't need one.

Is 2GP required for AppExchange listing?

No, 1GP packages are still supported and listed today, but Salesforce's tooling investment is squarely in 2GP, and most new ISV builds should start there. Talk to Tekunda or browse the blog if you're weighing this decision for an upcoming build.

Salesforce Connected App Security Changes: A Readiness Guide

Tekunda Team — Wed, 08 Jul 2026 12:00:00 GMT

Salesforce is moving Connected App access from "open by default" to "approved by default." Uninstalled Connected Apps are now blocked for most users, OAuth 2.0 Device Flow is being retired, and Salesforce is steering everyone toward External Client Apps as the long-term replacement. If your org hasn't audited what's actually authorized to talk to it, some integration will break before you find out why.

What is actually changing with Connected Apps?

Salesforce now blocks uninstalled Connected Apps by default, meaning any app a user authorized on their own, without an admin formally installing it in the org, loses access unless someone grants a specific bypass permission. Apps that still rely on OAuth 2.0 Device Flow lose access outright, even if they were previously authorized. Longer term, Salesforce is retiring the classic Connected App as the primary integration object in favor of External Client Apps, which separate the app definition from its policies and give admins finer control over scopes, IP ranges, and session behavior.

Why is Salesforce tightening this now?

The short version: OAuth authorization became a favorite target. Attackers impersonating IT support have talked employees into approving connected apps that looked legitimate, then used that access to pull data quietly over weeks. That's a social engineering problem, not a platform vulnerability, but Salesforce's response is architectural, making the default posture "nothing connects until an admin says so."

That shift is reasonable. It also means org hygiene that used to be optional, knowing exactly which apps have API access and why, is now the difference between a quiet Tuesday and an unplanned incident call.

Where do integrations actually break?

In our experience supporting Salesforce orgs through platform changes, the failures rarely show up where teams expect. Watch for:

Middleware and iPaaS connectors set up years ago by someone who's since left the team, with no documented owner.
Data Loader jobs and scheduled ETL scripts still using OAuth Device Flow for unattended runs.
Reporting or BI tools authorized by an individual user rather than installed org-wide.
Partner or ISV apps that were never formally installed, just authorized once during a pilot.

Any of these can pass unnoticed for months until the restriction kicks in and the sync job simply stops, often with no obvious error pointing back to the cause.

How do you audit your org before the restrictions bite?

This doesn't require new tooling, just a deliberate pass through Setup:

Open Setup > Connected Apps OAuth Usage and list every app currently authorized, not just the ones you installed.
Flag anything showing an "Install" action, that's your uninstalled, at-risk list.
Check last-used dates. Apps with no recent activity are candidates to revoke, not preserve "just in case."
Confirm your org's API Access Control policy and who holds the "Approve Uninstalled Connected Apps" permission.
For anything you keep, write down who owns it and why. That record is what saves you time during the next platform change, not just this one.

What should change in how you govern integrations going forward?

Treat this as a prompt to formalize integration governance, not a one-time cleanup. New integrations should be installed and scoped deliberately from day one rather than authorized ad hoc by whoever set them up. If you're planning new external connections, building them as External Client Apps from the start avoids a second migration later.

This is exactly the kind of work we do alongside internal Salesforce teams: mapping existing integrations, deciding what to keep, retire, or rebuild, and folding the result into a development process that treats access control as part of the release, not an afterthought.

If you'd rather have someone walk through your org's Connected App inventory with you before the next platform update lands, get in touch and we'll help you build the checklist into something repeatable.

FAQ

Will this break my existing Salesforce integrations?

Only if they're uninstalled or still use OAuth 2.0 Device Flow. Installed apps and modern auth flows keep working without changes.

What is the difference between a Connected App and an External Client App?

External Client Apps separate the app's identity from its access policies, giving admins more granular control over scopes and sessions; Salesforce is positioning them as the long-term replacement for classic Connected Apps.

Who should get the "Approve Uninstalled Connected Apps" permission?

Keep it narrow, admins testing new apps and developers maintaining integrations, since it's an all-or-nothing bypass rather than a per-app grant.

How often should we review Connected App access?

Quarterly at minimum, and immediately after any Salesforce security release, since authorization scope creep happens gradually and is easy to miss.

Planning a Salesforce Managed Package? Decide the Permanent 2GP Choices First

Tekunda Team — Tue, 07 Jul 2026 12:00:00 GMT

Short answer: If your team is about to build a Salesforce managed package on second-generation packaging (2GP), three of your earliest choices can never be undone: your namespace, the parts of your code you expose as global, and your version ancestry. Decide those on purpose before you write real code, and the rest of the lifecycle gets much calmer.

We work with product teams and ISVs who reach us after the hard part is already locked in. The pattern is always the same: the platform documents these rules, but it does not shout about which ones are permanent. This guide separates the decisions you must get right up front from the operational traps you can recover from later.

Which 2GP decisions can you never take back?

Three, and they are the ones teams tend to rush.

Your namespace is forever

The namespace you attach to a package cannot be changed or split later. It becomes the prefix on every component for the life of the product. If there is any chance you will one day separate or sell part of your portfolio, do not put everything under a single shared namespace, because you cannot untangle it afterward. Give this decision a proper review, not a quick guess in a scratch org.

Anything global stays global

Once you ship a member as global in a managed package, it is part of your public API permanently and you cannot remove it. Before you reach for global, check whether namespaceAccessible solves the problem instead: packages that share a namespace can share public Apex through it without exposing a global surface you will have to support for years.

Ancestry decides who can upgrade

Every released version declares an ancestor, and installed orgs only move upward along that chain. Choose the ancestor carelessly and you can leave customers on a branch that cannot reach your newest release. Understood early, the same mechanism is a gift: if a version goes wrong, you can branch your next release from an earlier, healthy one.

The operational traps that stall a release day

These will cost you time, but unlike the three above, you can recover from them.

Beta versus released. Every version you create starts as a beta that cannot install in production or reach subscribers until someone promotes it. A skipped promote step is the most common reason a "finished" package will not install.
The coverage gate lands at promote time. The 75 percent test-coverage requirement is checked when you promote for release, not when you create a beta. Teams that defer testing meet the wall on the exact day they planned to ship.
Dev Hub limits reset daily. Version creates and scratch orgs are capped per day by edition. Plan release days around the caps so you are not stranded until tomorrow mid-crunch.
Your Dev Hub is a single point of failure. Packages are owned by the Dev Hub org. Put it on an org a responsible person controls, not an expired trial, because ownership transfers are slow and painful.

How to make these decisions deliberately

The teams that ship packages smoothly are not luckier, they are earlier. They settle the permanent choices, namespace, global surface and ancestry strategy, in a short design session before any code exists, and they treat promote as a real gate with tests already in place. If you want a second pair of eyes on those decisions before they harden, that is exactly the kind of review Tekunda's Salesforce team does with product teams.

FAQ

What should we lock down before creating our first 2GP package?

The namespace, which Apex you expose as global, and your ancestry strategy. All three are effectively permanent, so agree on them before writing production code.

How do we avoid stranding customers on an old package version?

Plan your ancestry deliberately. Each version declares its ancestor and subscribers upgrade along that chain, so a wrong ancestor can block customers from reaching your latest release.

Why does our finished package refuse to install in production?

It is almost always still a beta. Betas only install in scratch and sandbox orgs. Promote the version to released before it can install in production or push to subscribers.

When does Salesforce enforce 75 percent test coverage for a package?

At promotion. You can build betas with low coverage, but the gate blocks promoting a version for release until coverage is met, so build tests in from the start.

Going the Extra Mile: Creating Exceptional Customer Experiences

Tekunda Team — Tue, 07 Apr 2026 04:07:16 GMT

First Impressions Last

In the digital realm, a customer's first interaction with your brand often sets the tone for the entire relationship. This could be anything from a well-designed website to the ease of navigation in your mobile application. In many instances, customers make up their minds about a business in the first few seconds. Therefore, immediate engagement is vital, offering something of value upfront - be it information, an exclusive offer, or even an engaging user interface - can turn a potential customer into a loyal one.

Personalisation is Key

Technology has enabled a level of personalisation that was previously unimaginable. With data analytics, it's possible to understand a customer's behaviour, preferences, and even anticipate needs. These insights shouldn't be ignored; they should be utilised to create a tailored experience. Personalised email campaigns, product recommendations, and customer service interactions all contribute to a sense of being valued and understood, which is essential for long-term customer retention.

Seamless Integration

Customer experience isn't limited to a single channel. It's a cumulative effect of interactions across various platforms and touchpoints. Whether a customer engages with your brand through social media, your website, or in a physical store, the experience should be seamless. Consistency in tone, messaging, and service quality is crucial for building trust and satisfaction.

The Role of Customer Service

Going the extra mile is often most apparent in customer service interactions. At Tekunda, we ensure our support teams are empowered to solve problems efficiently and make real-time decisions that favour the customer. This approach can turn a potentially negative experience into a positive one, creating customer evangelists who not only stay loyal but also promote your brand through word of mouth.

Feedback Loops

Open channels for customer feedback are invaluable. They not only identify areas for improvement but also present an opportunity to connect on a personal level. Acknowledging feedback and implementing changes shows a level of dedication and responsiveness that customers appreciate.

Make it Right

Mistakes are inevitable. It's how you handle them that defines your brand. Apologising sincerely and taking immediate corrective action can often win back a disgruntled customer. The 'front-page test' applies here; act in a way that would make you proud if it were reported in the media.

Exceeding Expectations

Small gestures can make a big difference. Whether it's a personalised thank-you note, an unexpected upgrade, or priority support, these 'extra miles' can transform customer satisfaction into customer delight. At Tekunda, we strive to inject this philosophy into every aspect of our operation.

Go the Extra Mile with Passion

Passion is not just a buzzword; it's an ethos. It's what drives us to continually improve and innovate. When this level of enthusiasm is evident in interactions with customers, it's contagious. It transforms the mundane into the extraordinary and creates memorable experiences that customers are eager to share.

Conclusion

In a saturated market, it's not enough to simply meet customer expectations; you must exceed them. Tekunda prides itself on not just offering solutions but also creating experiences that make each customer feel valued and understood. From the first interaction to ongoing support, every touchpoint is an opportunity to go the extra mile. And when you do, not only do you win a customer, you win an advocate.

Remember, the extra mile is never crowded. Make it your business to be there.

Freaky Friday! Team Building, Tech Talks: Why I Love Working here

Tekunda Team — Tue, 07 Apr 2026 04:07:04 GMT

I want to share a day that encapsulates why Tekunda is such an incredible place to work. Last week, our team took a break from regular work to dive into a day filled with learning, laughter, and genuine bonding. Check out the video to see how it all went down!

Kickstarting the Day with Games

We started our morning away from our desks, gathered in a conference room for some light-hearted games. "Two Truths and a Lie" kicked off the day. It's surprising how much you can learn about your teammates when trying to decipher the truths from the lie. Next, "Blind Drawing" had us in stitches, but also showed how communication is key in even the most chaotic situations.

Tech Talks by Our Very Own

What I love about Tekunda is that we're not just colleagues; we're a community of passionate tech enthusiasts. So, the afternoon saw five of our team stars presenting on hot tech topics like WebRTC, NextJS, Celery, and GraphQL. We believe in 'Knowledge Sharing,' and these sessions displayed just how much expertise we have within our walls. It was an awe-inspiring experience, seeing our own team members share knowledge that rivals any external tech conference out there.

Escape Room: The Clock Is Ticking!

After enriching our brains, it was time to challenge them. We ended the day with an escape room activity. There's nothing like a ticking clock to ignite team spirit and get everyone working together toward a common goal. Strategy, quick thinking, and teamwork led us to "escape," but it was clear that the real win was the collective problem-solving that got us there.

The Tekunda Spirit

Last week’s activities were a beautiful representation of our values and work culture. Tekunda isn’t just about delivering extraordinary digital experiences for our clients; it's also about making sure the team behind those solutions is engaged, informed, and excited about their work. We're not just employees here; we're a family committed to personal and professional growth, and these regular team-building days contribute to just that.

Come Join Us!

At Tekunda, you're not walking into a mere job; you're becoming part of an active, learning community. If this sounds like the kind of place where you'd like to grow your career, don't hesitate to apply. We’re always looking for passionate individuals to join our community of learners and doers. Check out our careers page to see the exciting opportunities we have available: Tekunda Careers.

So, that was our phenomenal day, and it's just the tip of the iceberg when it comes to why Tekunda is such an exceptional place to work. Big ups to everyone who contributed to making it a memorable experience.

#TeamWork #TechTalks #EscapeRoom #JoinTekunda

AI Agents in 2026: What Actually Works and Why Most Efforts Stalled

Tekunda Team — Thu, 26 Feb 2026 10:12:09 GMT

TL;DR

2025 was the year AI agents moved from heavy enterprise investment and bold promises to real-world scrutiny.

Enterprises poured budgets into agentic AI, platforms raced to embed agents everywhere, and analysts openly questioned whether many of these initiatives would survive.

Across startups, scale-ups, and enterprises, including teams like ours at Tekunda, the same lesson emerged:

AI agents only deliver ROI when they are embedded into real workflows, grounded in business context, and designed as operational systems, not autonomous experiments.

2025 Began With Massive Investment and Ended With Hard Questions

Early in 2025, AI agents became the central focus of global discussions. Agentic AI emerged as the prevailing theme in vendor keynotes, conferences, and boardroom discussions; it was the year when executive roadmaps shifted, and enterprises allocated serious budgets to AI adoption. Many expected widespread, rapid rollout into real-world practice, and industry research even reflected that momentum.

According to McKinsey, AI adoption across organizations reached historic highs, with most companies already using generative AI in some form and many planning to expand its role beyond copilots into autonomous systems.

At the same time, Deloitte projected that approximately 25% of enterprises would deploy AI agents by 2025, with adoption anticipated to double in the following two years as these agents became more integrated into core workflows.

However, alongside this acceleration, a second, less conspicuous narrative began to emerge.

By mid-2025, analysts began expressing concerns that the swift pace of adoption was exceeding organizational readiness.

Gartner issued a widely discussed warning:

Over 40% of agentic AI initiatives are expected to be abandoned by 2027, citing unclear business value, rising operational expenses, governance gaps, and what Gartner explicitly called “agent washing.”

That tension, between heavy investment and growing skepticism, clearly defined the year.

In short, 2025 marked the transition from enthusiasm-driven adoption to outcome-driven scrutiny, leading AI agents to move from “Can we build this?” to “Should we keep running it?” Large enterprises were not the only ones experiencing this tension.

Beyond individual teams, AI agents were increasingly viewed as a foundational layer of the next phase of the digital economy. Decisions made in 2025 about how agents were designed, governed, and integrated began shaping long-term productivity, cost structures, and operational resilience at scale.

The Gap You Only Notice Once You Start Building

What follows isn’t theory; it reflects what we learned firsthand building, deploying, and maintaining AI agents in real operational environments throughout 2025.

Teams actively developing AI agents, including startups, scaleups, and enterprises, encountered similar challenges.

On paper, everything was improving:

The models were more capable
Frameworks matured
Infrastructure was easier than ever to provision
You could build something impressive quickly
You could deploy it into a workflow

What proved much harder was making the value stick. This wasn’t a tooling problem or about model intelligence, it was simply an operational gap.

Agents were being built faster than teams, regardless of size, could integrate them into how work actually happens.

At Tekunda, we felt this early. As a modern, relatively small team building and deploying agents ourselves, the distance between a demo that works and an agent that earns trust became obvious rapidly.

That realization mirrored what we saw across the ecosystem, including inside much larger organizations.

Why Context Became the Real Differentiator

As agents moved deeper into real workflows, another limitation became impossible to ignore.

Generic intelligence didn’t scale trust.

Agents that relied on static prompts or surface-level understanding created friction:

Inconsistent answers
Misaligned decisions
Hesitation from users

The agents that survived were grounded in real business context:

How the organization actually answers questions
What data is authoritative
Which actions are allowed and which are not

This is where retrieval-augmented generation (RAG) emerged as a foundational element. Rather than being just a buzzword, it serves as a method to ensure that agents remain accurate, up-to-date, and aligned in real-world practices.

Conversation without context didn’t scale whether you were a startup or an enterprise. At scale, context was not just about accuracy; it defined authority, trust, and which systems were allowed to act without constant human intervention.

The Quiet Success of “Unexciting” Agents

By the second half of 2025, a counterintuitive truth became hard to ignore.

The agents creating the most value were barely exciting to watch.

They didn’t:

Reason deeply for long stretches
Plan autonomously across systems
Act without guardrails

They simply ensured that:

Nothing important was missed
Decisions were handled consistently
Humans started with clarity instead of chaos

These agents didn’t replace people. They reduced cognitive load.

And across teams of every size, that reduction proved more valuable than autonomy.

Across use cases, industries, and team sizes, the pattern was consistent: the closer an agent sat to real operational work, the more disciplined it needed to be.

Building agents taught us that reliability compounds faster than intelligence and that simplicity is often the hardest design constraint.

Adoption Became the Breaking Point

As analyst skepticism grew louder, it became clearer why so many initiatives stalled, not because agents were incapable but because they weren’t trusted.

Across organizations, agents struggled when:

Ownership was unclear.
Behavior felt opaque
Failure modes weren’t obvious.

Meanwhile, simpler agents with clear boundaries were adopted quickly and stayed in daily use, and that was the shared lesson that emerged across the ecosystem:

An agent people trust outperforms an agent that can do more. Adoption wasn’t a change-management issue, it was a design issue.

When adoption failed, the cost was not only frustration or inefficiency. It was the inability to convert investment, infrastructure, and intelligence into durable operational value, leaving many initiatives paused despite their technical capability.

Why Some Teams Slowed Down and Others Didn’t Recover

Looking back, many of the initiatives Gartner warned about shared similar traits:

Starting with AI possibility instead of real operational pain
Expanding scope too early
Optimizing for autonomy over reliability
Treating agents as experiments instead of infrastructure

The teams that succeeded small and large alike, did something counterintuitive during a hype cycle.

They slowed down early.
They scoped narrowly.
Validated feasibility.
Measured impact before scaling.

That restraint didn’t kill momentum. It made momentum sustainable.

What 2025 Actually Taught the Ecosystem

For teams building or evaluating AI agents in 2026, these became the non-negotiables we saw across the ecosystem:

Start with real operational pain
Automate volume before complexity
Ground agents in a business context
Design for trust, ownership, and recovery
Measure outcomes, not intelligence

The conclusion wasn’t dramatic, but it was clarifying:

AI agents create value by helping teams achieve greater outcomes without increasing the number of people involved.

That realization belonged to everyone building seriously in 2025.

Looking Ahead to 2026

In 2026, AI agents will increasingly move from experimental deployments into core operational and economic systems, raising the stakes for how responsibly and deliberately they are designed.

If 2025 was about proving what works, 2026 will be about operationalizing those lessons at scale, quietly and deliberately, with far less tolerance for experimentation without outcomes.

The next phase of AI agents will not be defined by louder promises or deeper autonomy.

It will be defined by teams who turn agents into reliable, contextual, operational systems.

2025 made one thing clear.

AI agents do not create value by being smarter, louder, or more autonomous. They create value by removing friction from real work.

The teams that succeeded, whether startups moving fast or enterprises moving carefully, used agents to:

Free people from repetitive loads
Reduce operational drag
Scale outcomes without scaling headcount

That philosophy mirrors how we approach systems at Tekunda.

Human-centered AI is not about replacing people. It is about giving teams back time, focus, and confidence in how work gets done.

The future of AI agents will not be defined by hype cycles. It will be defined by teams that quietly build systems that help people operate better under pressure, at scale, and in the moments that matter most.

FAQs - AI Agents in 2025-2026

What are AI agents?

AI agents are systems designed to interpret context, make decisions, and take actions within workflows. They utilize tools, data, and defined rules, going beyond merely generating text or responding to prompts.

Why did many AI agent projects struggle in 2025?

Most projects faced challenges not due to weak models, but because of unclear ownership, insufficient governance, poor integration into existing workflows, and difficulties in earning user trust.

Are AI agents only relevant for large enterprises?

No. Teams of all sizes, including startups, scale-ups, and enterprises, encountered similar challenges when agents were applied to real operations. Builders often recognized these limitations before organizations formalized them.

What actually drove ROI from AI agents in 2025?

ROI was primarily derived from automating high-volume, repetitive operational tasks; grounding agents in real business contexts; and focusing on design elements that fostered adoption, trust, and recovery, rather than on autonomy or novelty.

Is Agentic AI still worth investing in 2026?

Yes, provided that agents are integrated into the operations stack rather than treated as mere experiments. Teams that concentrated on leveraging workflows and achieving measurable outcomes experienced sustained value.

How React2Shell Led to Cryptomining in React and Nextjs Apps

Tekunda Team — Thu, 26 Feb 2026 10:10:39 GMT

TL;DR: In early December 2025, a critical vulnerability known as React2Shell (CVE-2025-55182) was disclosed in React Server Components. The issue allowed unauthenticated remote code execution in common React and Next.js setups, including default configurations. Exploits appeared quickly in the wild, with compromised servers used for cryptomining. If your application uses React Server Components or the Next.js App Router, patching and redeployment are required.

For years, frontend engineers were taught a reassuring mental model: The browser is the boundary.

Frontend code ran on the client, backend systems handled trust and security, and frameworks helped keep those responsibilities clearly separated. That model shaped how teams reasoned about risk, reviews, and deployment.

React2Shell broke that assumption in a very practical way.

In the days following the disclosure of CVE-2025-55182, teams across different roles reached the same conclusion from different direction, not because of theory, but because of what attackers did next.

Modern React applications are no longer just UI code. They execute as part of production infrastructure, and that shift made it possible for opportunistic campaigns to turn exposed servers into cryptomining workloads.

This wasn’t caused by misuse or exotic configurations. It widely affected adopted versions of React and Next.js running exactly as documented, which is why the impact spread quickly.

What Happened in React2Shell?

React2Shell is a critical vulnerability in React Server Components (RSC), a React feature that allows parts of frontend code to run on the server as part of handling real user requests.

What made this vulnerability different was not just where it lived, but how naturally it fit into normal request handling.

The vulnerability allowed attackers to trigger remote code execution (RCE), a class of attack where someone can run their own commands on a server by sending a specially crafted request, without logging in.

At a high level, the attack unfolded as follows:

A crafted request reached server-side React logic
Serialized input crossed a trust boundary
The server executed attacker-controlled code

Once that chain was understood, the severity became obvious.

The severity was immediately clear:

CVSS score: 10.0 (Critical)- the highest severity rating
Unauthenticated
Remote
Production impact

Proof-of-concept exploits appeared shortly after disclosure. Active exploitation followed soon after, leaving little time between understanding and exposure.

Why Default Applications Were Exposed?

One of the most important lessons from React2Shell is how ordinary the affected setups were. That ordinariness is exactly why the impact spread so quickly.

These were not:

Custom forks
Unsafe experimental builds
Edge-case deployments

They were:

React applications using these vulnerable packages (versions 19.0.0, 19.1.0, 19.1.1, 19.2.0):
Next.js versions ≥14.3.0-canary.77, 15.x, and 16.x using the App Router
Other affected frameworks: React Router (unstable RSC APIs), Expo, Redwood SDK, Waku, and Vite/Parcel RSC plugins

React Server Components fundamentally change where frontend logic runs. As a result, frontend code now:

Executes on the server
Handles serialized input
Participates in request processing

React2Shell didn’t introduce that shift. It simply forced teams to confront it.

Exploitation in the Wild and Cryptomining

Once the vulnerability became public, exploitation followed almost immediately.

Cloud providers and security researchers quickly began reporting real-world attacks, many of them opportunistic rather than targeted.

Compromised systems showed:

Cryptocurrency miners consuming CPU and memory- malicious software that forces servers to generate cryptocurrency for attackers
Backdoors dropped for persistence - hidden access paths attackers can reuse
Proxy tooling used to relay traffic
Follow-on activity typical of opportunistic attackers

In several reported cases, teams redeployed servers repeatedly, only to be reinfected. That pattern revealed the core issue.

The problem wasn’t cleanup. The vulnerable runtime was still in place.

Layered defenses helped, but they could not compensate for an unpatched core dependency.

🔍 The Technical Deep Dive for Security Engineers

At a high level, React2Shell was enabled by how React Server Components serialize and deserialize data using the React Flight protocol. Attackers were able to abuse that processing path to reach server-side execution, and in Next.js the same path could be triggered through request routing behavior tied to server actions.

For the full protocol-level breakdown, exploitation path, and mitigation details, read Darktrace’s technical analysis end to end.

The Frontend/Backend Boundary Is Gone

React2Shell clarified something that had been evolving quietly for years.

If your frontend framework:

Runs on the server
Accepts serialized input-structured data sent between client and server, such as JSON
Executes during request handling

Then it deserves the same operational scrutiny as any backend service.

This is not a failure of frontend engineering. It is the natural consequence of powerful abstractions becoming production infrastructure.

Modern frameworks trade explicit boundaries for speed and developer experience. That tradeoff doesn’t remove responsibility, it relocates it.

What Teams Needed to Do Immediately

As guidance emerged, response patterns converged across organizations. Teams that moved quickly followed the same playbook.

1. Identify exposure

Confirm the use of React Server components.
Verify whether Next.js App Router is enabled
Check indirect usage via dependencies.

2. Patch and redeploy

- Upgrade React Server DOM packages to 19.0.3, 19.1.4, or 19.2.3
- Upgrade Next.js based on your release line:
  - 13.x / 14.x: upgrade to 14.2.35
  - 15.0.x: upgrade to 15.0.5+
  - 15.1.x: upgrade to 15.1.9+
  - 15.2.x: upgrade to 15.2.6+
  - 15.3.x: upgrade to 15.3.6+
  - 15.4.x: upgrade to 15.4.8+
  - 15.5.x: upgrade to 15.5.7+
  - 16.x: upgrade to 16.0.7+

- Redeploy applications after upgrading, Restarting the application so the fixed version is actually running

3. Assume post-exploitation

Rotate secrets where appropriate
Review logs and runtime behavior
Monitor for abnormal resource usage

4. Treat framework upgrades as production changes.
Framework updates affect runtime behavior. They are not cosmetic.

The Bigger Takeaway

React2Shell did not break trust in React. It revealed how much trust modern stacks already carry by default.

The real shift isn’t “patch faster.” It’s recognizing that framework behavior is production infrastructure, and treating it with the same discipline applied to APIs, authentication, and deployments.

Every ecosystem balances:

Velocity vs visibility
Abstraction vs control
Convenience vs explicit boundaries

There is no perfectly safe stack, only well-understood ones.

Teams that handled this incident best were not the ones with the most tools. They were the ones that understood what executed where, and could respond deliberately.

Conclusion

React2Shell spread quickly not because it was sophisticated, but because it aligned with how modern frameworks are built and deployed.

If you run React Server Components or the Next.js App Router in production, treat this like any other runtime incident: patch, redeploy, and verify you weren’t already affected.

And going forward, apply the same rule everywhere: if it runs on the server, it deserves server-grade discipline.

FAQ

What is CVE-2025-55182?

React2Shell, a critical vulnerability in React Server Components that allowed unauthenticated remote code execution. It carried a CVSS score of 10.0.

Which React and Next.js versions were affected?

React 19.0.0, 19.1.0, 19.1.1 and 19.2.0, plus Next.js from 14.3.0-canary.77 through 15.x and 16.x when the App Router is used. React Router, Expo, Redwood SDK, Waku and the Vite and Parcel RSC plugins were affected too.

Is upgrading the package enough?

No. The running process keeps the vulnerable code until you redeploy, which is why several teams were reinfected after cleaning up without restarting on the fixed version.

How do you tell if a server was compromised?

Look for abnormal CPU and memory use from miners, unexpected outbound proxy traffic and unfamiliar persistence entries. Rotate secrets and review runtime logs even when nothing obvious shows up.

Resources

Tekunda Becomes an Odoo Partner

Tekunda Team — Wed, 10 Dec 2025 14:30:07 GMT

Expanding Unified Business Capabilities

Tekunda is now an official Odoo Partner, deepening our capabilities in delivering unified end-to-end business systems across operations, finance, sales, manufacturing, real estate, healthcare, retail, customer service, and more.

As a firm already strong in Salesforce consulting and integration, adding Odoo strengthens our ability to deliver the true “single source of truth” systems combining CRM and ERP, tailored to client workflows.

The two platforms are not competing; they’re complementary:

Salesforce remains the best-in-class platform for managing customers, growth, and revenue.
Odoo excels in ERP, operations, and back-office functions.

For SMBs, this balance means faster implementations, smarter automation, and reduced overhead.

Facing Integration Headaches?

Are your CRM and ERP still speaking different languages, leaving teams to hand- translate data between orders, inventory, billing, and service?

Q: Why Tekunda & Odoo Partnership Matters?

Every business system comes with its own schema, API limitations, and authentication model. None of them agree on what a customer, order, or status means. That’s why businesses end up hand-translating data between CRM, ERP, accounting, and warehouse systems until something breaks.

Our approach is simple: design automated workflows that reflect the way you actually run your business. Integrations are configuration-based, not heavy custom development. We deliver this as a managed service, so when Salesforce or Odoo update their schemas, nothing silently dies.

This pain is universal, but it becomes manageable when integrations are built creatively: configuration-driven, flexible, and aligned to your processes.

CRM & ERP built for SMBs

Salesforce for growth. Odoo for operations. Unified workflows that scale with your business.

See how it works

Q: What do clients actually gain?

Unified CRM + ERP Integration
Your systems don’t just coexist; they work together. Sales orders, invoicing, inventory movements, financials, and customer touchpoints sync bi-directionally.
Custom Workflows That Fit You
We don’t do “install and go.” We map workflows across sales, fulfillment, service, supply chain, healthcare, and retail, then configure Salesforce and Odoo to fit.
Scalable Architecture
Start with essentials and expand into manufacturing, procurement, HR, MRP, or healthcare modules. Integration patterns are built for long-term extensibility.
Better Visibility & Decision Support
Leadership gains dashboards that combine ERP operational metrics with CRM data, revealing which sales convert to profit, where bottlenecks occur, and how resources should shift.
Reduced Overhead & Manual Work
Automations across order-to-cash, procurement, and service reduce duplication, reconciliation, and errors.
Ongoing Support & Optimization
CRMs and ERPs aren’t “set and forget.” We evolve your systems as your business changes.

Start with a workflow mapping.

Not sure where to begin? We’ll map your CRM or ERP processes into one seamless flow.

Book a workshop

Why Tekunda?

Dual expertise: Salesforce and Odoo, complementary not competing.
Integration-first mindset: Data flows before features.
Stakeholder alignment workshops: Sales, Ops, Finance and Care teams aligned early.
Phased rollouts: Essential first, adoption first, then expand.
Agnostic extension/API capability: Where standard modules stop, we build bridges.
Domain expertise: Experience in manufacturing, healthcare, retail, real estate, SaaS.

Real-World Scenarios

Manufacturing: Salesforce handles lead-to-order. Odoo drives inventory planning, procurement, production, and invoicing. Sales forecasts automatically inform material planning.
Services + Product: Salesforce closes deals; Odoo fulfills service orders. Agents see contracts and stock status on one screen.
Healthcare Provider: Patient interactions in Salesforce feed into Odoo’s scheduling and billing - ensuring compliance and smooth care delivery.
E-Commerce Brand: Orders from Salesforce or storefronts flow into Odoo’s warehouse. Financials and returns post back automatically.

What Happens Next?

Already on Odoo or another ERP and need CRM? We’ll build the workflows to unify them.

Want a sanity check on your integration approach? We’ll map your workflows and show you how to avoid brittle hand-offs.

Reach out for a workshop or send us a DM to see how unified systems behave in practice.

See Odoo in action.

Experience how SMBs unify customer, finance, and operations on one platform.

Book a Demo

Beyond Partnership: Expanding What’s Possible

This partnership isn’t about adding another tool, it’s about expanding what’s possible.

Odoo brings a complete suite of ERP capabilities, from finance and manufacturing to retail, healthcare, and beyond. Paired with Salesforce’s CRM strength and our integration expertise, SMBs can finally access end-to-end workflows on a single, flexible platform.

The businesses that thrive tomorrow will be those whose systems are fluid, adaptive, and future-ready.
With Odoo as the operational backbone and Salesforce as the growth engine, the path to an integrated, intelligent business is clearer than ever.

TL;DR

Tekunda’s Odoo Partnership pairs Salesforce for growth with Odoo for operations, unifying CRM and ERP into one extensible workflow.
Result: Faster implementations, less manual work, and better decision-making for SMBs.

FAQ

Do Salesforce and Odoo compete with each other?

They overlap at the edges but solve different problems. Salesforce runs customer, growth and revenue processes, while Odoo covers ERP, operations and the back office.

Can Salesforce and Odoo share one customer record?

Yes, with a bi-directional sync. Orders, invoices, inventory movements and customer touchpoints flow both ways once you agree what a customer, an order and a status mean in each system.

Does a CRM and ERP integration need custom code?

Most of it should be configuration-driven. Custom code belongs where standard modules stop, and keeping that surface small is what makes upgrades survivable.

What breaks CRM to ERP integrations over time?

Schema and API changes on either side. Running the integration as a managed service means those updates get caught and adjusted before something silently stops syncing.

What It Takes to Drive ROI from AI Agents? (From a Team That Does It)

Tekunda Team — Mon, 20 Oct 2025 19:52:07 GMT

If you're reading this, chances are your team is exploring AI agents, maybe you've built a prototype, or you're evaluating whether agents can actually deliver ROI in your business.

At Tekunda, we've spent the last year building and deploying real-world AI agents for product teams, internal ops, and client delivery. And here’s what we’ve learned:

Yes, AI agents can deliver major returns, but only if approached with the right expectations, structure, and execution strategy.

Ready to explore AI agent ROI?

Speak to a Tekunda partner and see how AI agents can cut hours of repetitive work without the hype.

Book a consult Share your use case

It’s Not About AI Hype, It’s About Workflow Automation

Most of the ROI we’ve seen doesn’t come from generative text or chatbots. It comes from automating repetitive decision-making tasks that used to require hours of human input.

Think: lead qualification, data enrichment, triage, internal routing, follow-ups, and more.

The trick is building agents that integrate tightly with your existing systems, Salesforce, Notion, Google Workspace, Slack, CRMs, and perform useful actions without needing constant oversight.

Understand What Agents Can and Can’t Do

Teams waste months trying to build what’s technically unfeasible (or too brittle to maintain). Example:

LinkedIn messaging agents? Not possible through LinkedIn's official APIs. Third-party hacks exist, but they’re unstable, risky, and not worth building real operations on.

Start by mapping pain points, then validating feasibility. We help teams run that assessment before writing a line of code, it saves time and budget down the line.

Real ROI Comes from Solving Boring Problems

The highest-leverage agents we’ve built didn’t look fancy, they just:

Saved someone 10+ hours a week
Closed the loop on neglected ops tasks
Increased conversion speed

Examples include:

Auto-sending personalized emails to leads using LinkedIn data + CRM signals
Following up on stale tickets in support workflows
Summarizing sales calls and updating opportunity fields

Agents don’t need to “wow”, they need to help your team move faster.

ROI Is a Function of Internal Buy-In

You can build the smartest agent in the world, but if no one uses it, it delivers zero value.

That’s why agent adoption depends on:

Clear ownership: who maintains and improves the agent?
Simple UX: do internal users trust and understand it?
Ongoing feedback: is it evolving with team needs?

We often say: a mediocre agent with strong adoption beats a genius agent no one uses.

No-Code = Great for Testing. Not for Scale.

We love tools like N8n, Zapier, and Make, but for production-grade deployments, they often hit limits:

Performance bottlenecks
Cost scaling (node-based pricing can spike)
Debugging black boxes

From prototype to production, without the pain

We help teams move from no-code demos to production-grade agents using Langflow, Python, LangChain, and LangGraph.

Schedule a discovery sprint

For clients targeting ROI, we recommend:

Low-code + code (Langflow, Python, LangChain, LangGraph)
Version control to track changes
Hosted agent orchestration (Cloud Run, Vercel, or similar)

When (and How) to Use LangChain, Lessons from Thousands of Deployments

We spent months analyzing LangChain usage patterns across 500+ companies, from Fortune 500s to early-stage startups. What we discovered completely contradicts the official documentation.

89% of successful production LangChain apps ignore the official patterns entirely.

What Successful Teams Actually Do:

1. Memory Management
Docs recommend: ConversationBufferMemory()
Reality: 76% of teams build custom memory handlers to avoid leaks and token bloat.

# Custom production-safe memory
class CustomMemory:
    def __init__(self):
        self.redis = Redis()
        self.max_tokens = 4000  # Hard limit

    def get_memory(self, session_id):
        # Pruning, compression, etc.
        pass

2. Chain Composition
Docs recommend: LCEL
Reality: 84% of production teams avoid LCEL altogether - citing poor observability and error handling.

# What works in production:
def run_chain(input):
    try:
        prompt = format_prompt(input)
        response = call_model(prompt)
        return parse_output(response)
    except Exception as e:
        logger.error(f"Chain failed: {e}")
        return fallback_response()

3. Agent Frameworks
Docs recommend: LangGraph
Reality: 91% stick to basic ReAct-style agents or write custom logic.

Why? LangGraph is hard to debug, and often extends time-to-production by months.

The Real LangChain ROI Pattern

Use LangChain’s utilities, like document loaders or text splitters
Write your own orchestration logic
Handle memory and error handling yourself
Use direct API calls for performance-critical paths

Some of the highest-performing agents we’ve seen were built with 10% LangChain, 90% raw Python.

LangChain works best when you use it least.

Success Requires Cross-Functional Thinking

Agent ROI is not just about the code, it’s about integrating across business, tech, and ops teams.

Your org needs someone who can:

Translate business pain points into agent actions
Prompt engineer and QA agent logic
Secure stakeholder buy-in with clear reporting on outcomes

Without this glue, agents become side projects that never cross the finish line.

Qualify the Use Case First, Then Build

Before committing dev time, we ask:

What’s the time saved or revenue impact?
Can the task be clearly scoped and validated?
Will someone own the agent after deployment?

If the answers are unclear, we recommend holding off, or building a throwaway prototype to test assumptions.

TL;DR: Agent ROI Comes from Focused, Measurable Impact

If your business is chasing shiny AI features, you’ll burn through time and money fast.

But if you’re focused on automation, integration, and solving real problems? That’s where agents pay off.

To get meaningful ROI, your team needs to:

Start with real internal pains, not AI FOMO
Understand agent limitations and trade-offs
Build for adoption, not just capability
Treat agents as part of your ops stack, not toys

If you're exploring agent adoption at your company and want to see what ROI looks like in practice, reach out to us at Tekunda. We’ve built agents for sales, support, RevOps, DevOps, and more, and we’re happy to share patterns that actually work.

Now is the best time to get this right, while others are still playing with prototypes, you could already be automating the edge.

FAQ

Where does AI agent ROI actually come from?

From automating repetitive decision work: lead qualification, enrichment, triage, routing and follow-ups. Generative text on its own rarely pays for itself.

Are no-code tools enough for production agents?

They are excellent for testing an idea. At production volume teams hit performance ceilings, node-based pricing and black-box debugging, so the core logic moves into code.

How do you choose the first agent use case?

Start from a real operational pain, confirm the task can be scoped and validated, and check that someone will own the agent after launch. If any of those is unclear, prototype first.

Why do internal AI agents go unused?

Adoption fails when ownership is unclear, the interface is confusing, or feedback never reaches the people maintaining it. A simple agent people trust beats a clever one nobody opens.

Start automating today

While others are still testing prototypes, you could already be running production-grade AI agents that save time and drive revenue.

Contact Tekunda Schedule a Demo