Why Build?
Why build a connector?
Your particular business needs may call for a newly built connector, instead of using one of the App Connectors or Universal Connectors. This page will help you assess the need and advantages of building your own connector. If a new connector is desired and feasible, proceed to Pre-Development Considerations for more information and our technical SDK documentation.
Key Benefits
The key benefits of deploying a connector on the App Xchange platform include:
Availability to the existing App Xchange user base already developing integrations with other connected products and applications.
Connecting a product to the App Xchange platform can ease the path to adoption for users of other connected products. Build one connector for an application, and get access to integrate with many other applications that already have connectors on the platform.
Pre-built integrations: building a connector enables developing pre-built integrations on top of it that may cover a variety of common use cases.
What is the pricing model of connectors on the platform?
There is no extra direct cost to an end user to leverage a standard connector on the platform.
In App Xchange for Products, typically used by technology company developers building integration products for their users, there is a limit to the number of connectors non-enterprise users can leverage per integration. This is a pricing tier for the platform not directly tied to any individual connector. That limit does not apply to App Xchange for Contractors, typically purchased by end users building their own custom integrations.
If there is a cost to use the connected product or API, the user can pay that directly (not in App Xchange). The user will be able to enter any credentials provided if needed for the connector on App Xchange.
The benefits of providing a connector include access to integration with a variety of other applications on the platform, encouraging adoption of the connected product.
How can I evaluate the revenue potential of building a connector?
Even if a product or application enables direct integration capabilities, for example by providing an API, typically only developers will be able to leverage it, and they will need to invest in building custom logic to achieve the integrations needed. This may be a barrier to adoption for potential users, which can be difficult to quantify accurately.
It may be useful to evaluate the demand for a connector by performing any of the following exercises:
Interview current users with custom-built direct integrations (e.g., leveraging an API directly) to weigh their interest in using the connector (for example, if they'd prefer not to continue investing in the current development effort).
Evaluate the cost, if any, of building integrations on behalf of existing users who cannot develop their own.
Analyze user behavior to determine if churn or attrition is due in any part to the cost (or lack of) integration paths available.
Perform an analysis of products with complementary features or data to evaluate if a connector may provide an adoption path of benefit to them or their users.
In general, the most-used features of a product can be identified based on current usage patterns, log data, and user engagement or feedback. This data can be leveraged to better understand what kinds of integration are in demand. By focusing on these when building a connector, broader adoption can be enabled with lower initial development effort, thereby maximizing earning potential.
It can be difficult to quantify this in general terms, in that the data will vary widely between products or applications.
By focusing early development on targeted integrations and prioritizing the most in-demand features, the investment to build a connector can be effectively managed while beginning to collect initial data on its usage by early adopters on which to base enhancements later if needed.
In addition, by enabling new custom or pre-built integrations on the platform, long-term adoption of the connected product or application will be encouraged.
What is the estimated level of effort to build a connector?
The level of effort involved in building a connector will depend in large part on the complexity of the application or product and of the integrations the connector will enable. That can be evaluated in a number of ways, and can be mitigated by prioritizing the most in-demand features needed. Additionally, intermediate C# development skills are required as described in our SDK documentation.
Building a connector may be thought of as including three phases of work:
Initial onboarding: We'll engage directly with new teams to prepare any needed components and provide initial direction.
Build as needed for integration use cases: This will depend on the integrations to be enabled and may involve continued engagement with the App Xchange team on platform capabilities and documentation.
Deploying to production: The connector build approval and deployment pipeline is evolving. This page will be updated as further documentation becomes available on the connector lifecycle.