External connections
Connect another service with the right project context
Describe the external service to connect, provide its documentation and associate it with the relevant business areas.
Bring documentation and access details together
- Declare the service
Identify the external API and provide a documentation link or text.
- Separate access details
Supply the test and production credentials requested for the connection.
- Link the business context
Associate an existing connection with the areas that use it.
Give an integration the information it needs
A connection starts with the service name and documentation. Explain which business action requires it and the information that should move between the systems.
The declaration supports separate test and production access details. Review those details on the connection’s detail page, keeping the environment context clear.
Prepare an integration around the business action it supports
Explain the exchange you need. An external service may supply or receive information used by a business task. Declare its name and documentation, then explain the intended exchange in the project context. This gives the integration a practical purpose beyond a service URL.
Distinguish testing from production. Test and production credentials can belong to different provider accounts. Keep them in the corresponding fields and verify their intended use. Separating those contexts helps prepare the integration for its development and live stages.
Reuse a declared connection. The same external service can support several business areas. Link the existing connection where it belongs, then review its associations. Detaching it from an area and deleting it from the whole project are different decisions.
Reuse the connection where it belongs
A declared connection can be linked to more than one business area. Inspect the linked connections in an area and attach or detach the appropriate service.
Declaring the service supplies the integration requirements. Review its status and test the completed business workflow before relying on it in production.
Explain the exchange your application needs
Specify the service, the information to send or receive and the business area that uses it. A link to current documentation helps describe the actual external contract.
Describe a useful example and the expected response when the service is unavailable. The connection can then be discussed in terms of your users’ work, not just a provider name.
From service declaration to a tested workflow
Supply the service information. Provide a documentation link or its content and the requested access details. Identify the business operation requiring the connection.
Associate the right areas. Attach the declared connection to the areas that use it. Review the existing associations before adding or removing one.
Verify the completed integration. Follow its state and test the intended exchange in the relevant environment. Declaration alone does not prove that the workflow is working.
Prepare the connection your application actually needs
Start with the service documentation and the business outcome. Keep access details and associations clear throughout the project.
Questions about External connections
Provide the external service name and a documentation link or pasted content. Supply the access details requested for testing and production. A name alone does not define the integration’s behavior.
An existing connection can be associated with multiple business areas. Review the linked areas in the connector details so its scope remains understandable.
An external connection describes how your application uses another service. The optional project API exposes your application’s agreed operations. They serve different integration needs.
Detaching a connector concerns its link to one area. Removing the connector from the project is a separate action with a different scope; review the confirmation before proceeding.
Follow implementation and test the complete business exchange. The declared service and its activation state are useful context, but do not replace verification of the result.