REDA AI over MCP is live: your configured agents, inside Claude. Explore the connection →
Workflows & integration

AI configuration, integration and custom development: where each belongs

“Configurable” is useful only when you know what can be configured. A business procedure, an external connection and a new transaction rule are different pieces of work—and they need different owners.

At a glance

  • Configuration adapts capabilities that already exist.
  • Integration makes the required information or action reachable.
  • Custom development adds behaviour that needs its own testing and maintenance.

Configuration starts with business knowledge

An administrator may set an agent’s role, instructions, relevant context, available tools and suggested questions. The process owner supplies the meaning: what counts as complete, which policy applies, what an exception looks like and where the agent must stop.

REDA AI includes administration tools that can propose improvements to instructions and context. Those suggestions need review. An optimised prompt is not proof that the workflow is accurate, that a new system has been connected or that a permission has been enforced. Explore agent configuration.

Illustrative delivery responsibilities
  1. Define the procedure
  2. Configure available tools
  3. Connect missing systems
  4. Test the complete workflow

Integration answers a different question

If the relevant document status lives in another application, an instruction to “check the document status” does not create access to it. Someone must establish the connection, authentication, data mapping, permitted operations and error handling.

Before estimating that work, identify the authoritative system and the minimum information needed. A scheduled import or existing approved service may be sufficient; a real-time integration is not automatically the right choice.

When custom development is justified

A purpose-built tool can be useful when a business action must validate several conditions or coordinate a specialised process. Its interface should make the permitted operation clear and reject unsuitable inputs.

Salesforce’s Apex security documentation distinguishes sharing from object and field access. Developers must account for the relevant execution mode and access controls in their implementation. A prompt that tells the agent to respect permissions does not replace that work. [1]

A worked example: preparing a renewal brief

WorkstreamIllustrative responsibility
ConfigurationDefine the briefing structure and which available account fields are relevant.
IntegrationRetrieve a permitted summary from the support system if it is not already in Salesforce.
Custom development, if neededAdd a narrowly scoped action for a business-specific renewal process.
Process ownershipDecide who reviews the brief and which commercial decisions remain with the team.

You might discover that all the required information already exists in Salesforce and no new integration is necessary. Or the external system may be essential. Both are legitimate outcomes of discovery.

Make the handover clear

For each component, record who can change it, how a change is tested and who handles a failure. Include the business owner, Salesforce administrator and any integration or development specialist. Keep credentials and sensitive records out of general-purpose instructions.

REDA acts as an AI innovation partner around this complete workflow. The platform is horizontal; the delivery choices should fit your processes and existing technology. Start with the dependencies you already know rather than assuming either “no code” or a large custom build.

Sources

  1. Salesforce Developers — Secure Apex classes. Accessed 22 September 2026.
Your process. Your priorities.

Put the idea in your business context.

Bring your workflow and the people who know it. We can explore what a useful first evaluation would look like.

Discuss your workflow