AppLink Fundamentals III: Building with AppLink – Development Flow and Language Choices
- Last Updated: July 31, 2025
This blog series has taken you on a journey through the world of AppLink, from its foundational concepts and core components in Heroku AppLink: Extend Salesforce with Any Programming Language, to a deep dive into its key integration patterns in AppLink Fundamentals I: AppLink Integration Patterns – Connecting Salesforce to Heroku Applications, and then we explored advanced integrations with Data Cloud, automation, and AI in AppLink Fundamentals II: Advanced AppLink Integrations – Automation & AI. Now, in this final installment, we turn our attention to the practical aspects of building with AppLink, focusing on the development workflow, including local testing and managing changes to the OpenAPI specification, and crucial considerations when choosing the best programming language for your Salesforce extensions.
Tell me more about integrating with Agentforce?
Agentforce integration leverages AppLink’s full computational flexibility to extend agent capabilities far beyond native Salesforce functionality. Due to the compute power and framework availability at developers’ disposal, agents can return rich content – not just text data – including generated images, PDFs, complex calculations, and processed data from external APIs.
The Heroku Agentforce Tutorial provides comprehensive step-by-step guidance for creating custom Agent Actions, from initial setup through production deployment.
Real-world example: Automotive finance agent
Car dealership agents need to provide instant, competitive finance estimates that consider complex pricing rules, customer credit profiles, and generate professional documentation. Here’s how a Koa Cars Finance Agent performs real-time credit assessments, applies complex pricing rules, and generates professional PDF agreements:
Customer: Finance estimate request
↓
Agent: "What's your contact email?"
↓
Customer: "johnsmith@codey.com"
↓
Agent: "Which car model interests you?"
↓
Customer: "I'm interested in the Zig M3 car"
↓
Agent: Calls Heroku Finance Service

The service also automatically generates a professional PDF finance agreement:

This demonstrates AppLink’s capability to handle complex business logic including multi-tier interest rate calculations, real-time credit assessments, dynamic pricing with dealer incentives, and automatic PDF generation – all while seamlessly integrating with Salesforce CRM data.
Enhanced OpenAPI configuration for agent actions
Agentforce requires additional OpenAPI YAML attributes beyond standard external service configuration. AppLink automatically handles these specialized requirements when you include the appropriate x-sfdc
agent extensions:
x-sfdc:
agent:
topic:
classificationDescription: "This API allows agents to calculate automotive finance estimates, assess credit profiles, and generate professional documentation."
scope: "Your job is to assist customers with vehicle financing by providing instant competitive estimates, applying complex pricing rules, and generating finance agreements."
instructions:
- "If the customer asks for finance estimates, collect contact email and vehicle model information."
- "Use real-time credit assessment and dealer-specific pricing rules for accurate calculations."
- "Generate professional PDF agreements and attach them to Contact records automatically."
name: "automotive_finance_topic"
action:
publishAsAgentAction: true
isUserInput: true
isDisplayable: true
privacy:
isPii: true
These extensions enable:
- Agent Topic Generation: Creates logical groupings of related actions for agent organization – agent topics help agents understand when and how to use your services
- Action Publishing: Automatically makes your endpoints available as Agent Actions within the defined topic
- User Input Configuration: Controls whether fields require additional user input
- Display Configuration: Determines which response fields are shown to users
- Privacy Controls: Enables PII handling for sensitive operations
For complete details on OpenAPI configuration for Agentforce, see Configuring OpenAPI Specification for Heroku AppLink.
Development flow
The AppLink development workflow supports rapid iteration across Salesforce environments, from scratch orgs to production deployments. Understanding the development tools and processes ensures smooth implementation and reliable deployments.
Local development
Local development with AppLink focuses on testing Pattern 2 applications (Extending Salesforce) that receive requests from Salesforce. Pattern 1 applications (API access) don’t require special local testing since they make outbound calls to Salesforce APIs directly.
The invoke.sh
script (found in /bin
folders of sample applications) simulates requests from Salesforce with the correct headers, enabling local development and testing before deployment. For example, see the Pattern 3 invoke.sh
script for testing batch operations locally.
Usage: ./bin/invoke.sh [session-based-permission-set]
The script provides several key features for development workflow:
- User Authentication Simulation: The script uses the Salesforce CLI to extract org details including access tokens, API versions, and org identifiers. It constructs the required
x-client-context
header with base64-encoded JSON containing authentication and context information that your application would receive from Salesforce in production. - Permission Set Testing: For applications requiring elevated permissions (user mode plus), the script supports session-based permission set activation through a third parameter. It automatically creates and removes
SessionPermSetActivation
records, allowing developers to test permission-dependent functionality locally before deploying to environments where these permissions would be granted through Flows, Apex, or Agentforce configurations. - Request Payload Simulation: The script accepts JSON payloads as parameters, enabling testing of various request scenarios and edge cases. This capability is essential for validating business logic and error handling before moving to integration testing.
To use the invoke.sh
script for local testing, authenticate with your target org using the Salesforce CLI, then execute the script with your org alias and request payload:
# Authenticate with your Salesforce org
sf org login web --alias my-org
# Install dependencies and start local development server
npm install
npm run dev # or npm start depending on your package.json scripts
# In a separate terminal, test locally with simulated Salesforce headers
./bin/invoke.sh my-org 'http://localhost:8080/api/generatequote' '{"opportunityId": "006am000006pS6P"}'
This local development workflow integrates seamlessly with your existing Node.js development tools – use nodemon
for auto-reloading, your preferred debugger, and standard logging libraries. The invoke.sh
script is language and framework agnostic, working with any technology stack you choose for your Heroku application.
Managing changes to the OpenAPI specification
Managing changes in the interface between your Heroku application and Salesforce requires careful attention to the OpenAPI specification file that defines your service contract. This specification serves as the single source of truth for both your application’s API endpoints and the Salesforce components that consume them.
When developing new features or modifying existing endpoints, maintaining specification alignment prevents breaking changes that could disrupt dependent Salesforce components. The OpenAPI specification defines not only the request and response schemas but also the HTTP methods, status codes, and error formats that your consuming Flows, Apex classes, or Agentforce Actions expect.
Salesforce enforces this alignment through validation during the publish process. If you attempt to publish an updated application with breaking changes to an existing specification, and there are active Apex classes, Flows, or Agentforce Actions referencing those endpoints, the publish command will fail with validation errors. This protection mechanism prevents accidental service disruptions in production environments.
For development environments where you need to iterate rapidly on service interfaces, scratch orgs provide the flexibility to start fresh when needed. However, if you’re working with persistent sandboxes or production environments, you have two options when breaking changes are necessary: either remove all references to the modified endpoints from your Flows, Apex classes, and Agentforce Actions before publishing, or use a different client name parameter in the CLI publish command to create a parallel service definition, for example --client-name MyService_v2
.
Using scratch orgs
Scratch orgs represent the optimal development environment for AppLink applications, particularly when your service interfaces change frequently during development. Unlike traditional sandboxes, scratch orgs provide a clean, disposable environment that can be recreated as needed when breaking changes occur or when you need to test deployment scenarios from ground zero.
The key advantage of scratch orgs for AppLink development lies in their ability to start fresh without the complexity of cleaning up existing references, published applications, or permission configurations. When your service evolves significantly, you can create a new scratch org, configure the necessary features, and test your complete deployment pipeline without worrying about conflicts from previous iterations.
To configure a scratch org for AppLink development, you must enable the required features in your scratch org definition file. For standard Salesforce integration, include the HerokuAppLink
feature in your project’s config/project-scratch-def.json
:
{
"orgName": "AppLink Development",
"edition": "Developer",
"features": ["HerokuAppLink"],
"settings": {
"lightningExperienceSettings": {
"enableS1DesktopEnabled": true
}
}
}
For Data Cloud integration scenarios, also include the CustomerDataPlatform
feature alongside HerokuAppLink
. Once configured, create and authenticate with your scratch org using standard Salesforce CLI commands, then proceed with your AppLink connection and deployment workflow.
Scratch orgs excel in scenarios where you’re developing new integration patterns, testing permission model changes, or validating deployment automation. They provide the confidence that your deployment process works correctly from a clean state, which is essential for production readiness. While traditional sandboxes remain valuable for longer-term testing scenarios and stakeholder demonstrations, scratch orgs offer the rapid iteration cycle that modern development practices require.
CI/CD integration
The JWT-based authentication flow (heroku salesforce:connect:jwt
) integrates seamlessly with scratch org workflows, enabling automated connection setup as part of your CI/CD pipeline. This capability allows you to script complete environment provisioning, from scratch org creation through application deployment and testing, providing reproducible development environments for your entire team.
Coding language choices
When extending Salesforce functionality, choosing the right programming language depends on your specific requirements, team expertise, and operational constraints. While Apex remains a powerful option for many scenarios, AppLink opens up the entire spectrum of modern programming languages, each bringing unique capabilities and development ecosystems to your Salesforce solutions.
The following comparison helps you understand the tradeoffs between Apex and other programming languages when building Salesforce extensions, highlighting where each approach excels and the specific capabilities that become available when hosting code on Heroku using the AppLink add-on. Consider using Apex for transaction-critical operations requiring database triggers and system-level access, while leveraging AppLink and modern programming languages for computationally intensive tasks, external integrations, and scenarios where existing code investments can be preserved and extended.
Capability | Apex | Node.js, Python, Java…* |
---|---|---|
Fully Managed Trusted Infrastructure | ✅ | ✅ |
Extend Apex, Flow and Agentforce | ✅ | ✅ |
Record Update Logic in Transaction | ✅ | Triggers not supported |
Secure by Default | With Annotations | ✅ |
Run as User | With Annotations | ✅ |
Run as System | Default | Principle of Least Privilege** |
Limits Handling | Fixed CPU Timeout, Heap and Concurrency Limits | Elastic Horizontal and Vertical Scale*** |
Extend Existing Code Investment | N/A | ✅ |
* Capabilities only available when hosting code on Heroku using the Heroku AppLink Add-on
** Heroku logic can leverage Session-based Permission Sets to elevate beyond user permissions
*** Salesforce API limits still apply; use Unit of Work patterns to make optimal use of updates
AppLink also enables developers with skills in your wider organization or hiring pool to contribute to Salesforce programs using languages they’re already proficient in, expanding your team’s ability to deliver sophisticated Salesforce extensions without requiring specialized Apex training.
Summary
AppLink represents a fundamental shift in how developers can extend Salesforce, breaking through traditional platform limitations to bring unlimited computational flexibility to the Salesforce ecosystem. With enterprise-grade security through User Mode authentication, seamless integration where Heroku applications appear natively within Salesforce through generated Apex classes, Flow actions, and Agentforce capabilities, and support for unlimited language choice in Node.js, Python, Java, and other languages, AppLink bridges the gap between Salesforce’s declarative power and unlimited programming flexibility.
Whether you’re extending core CRM functionality, building sophisticated agent actions, or integrating with external systems, AppLink provides the foundation for enterprise-grade Salesforce extensions using the languages and frameworks you know best.
Read More of the AppLink Fundamentals series
- AppLink Fundamentals I: AppLink Integration Patterns – Connecting Salesforce to Heroku Applications
- AppLink Fundamentals II: Advanced AppLink Integrations – Automation & AI
- AppLink Fundamentals III: Building with AppLink – Development Flow and Language Choices
- Originally Published:
- AppLinkAppLink FundamentalsIntegrationssalesforce