For API integrations, the External Source Configuration section defines the identity and behavior of each data source within the system. When configuring API services, this section is used to populate key fields such as Name, ID, Description, Category, and other settings that determine how messages are routed and managed for both Inbound and Outbound sources.
Refer to the Operations IQ Platform Help Content for full guidance on how to create and populate these fields. This setup is required for enabling custom data inbound sources, scheduling feeds, or CMS-related configurations.
Inbound External Source Best Practices
Name string [required]
A descriptive title that identifies the source system or integration. This should reflect the purpose or origin of the inbound data. An inbound source for production data that comes from an enterprise integration platform such as Workato might be:
Example: "Production Workato Custom Data Inbound Source"
ID string [required]
A unique identifier for your inbound source. This is used as a reference value in API payloads (e.g., the externalSource field in the body). Think of this as a short name or abbreviation.
Example: An inbound source for production data that comes from an enterprise integration platform such as Workato might be "PrdWrkCDIS" or “PWCDIS”
Description string [optional]
Additional context or notes describing the source’s purpose or role. This helps with system tracking and clarity during configuration reviews.
Example: "Inbound source for custom data exchange for North Facility"
Category string [required]
Set this to “Ordering.” For inbound API sources, this can be set to ADT if ADT is the inbound source. However, CMS cannot be used as the inbound source for API-based integrations.
Example: “Ordering”, “ADT”
Inbound Message Forwarding URL string [Not Used]
Not used for API Sources
On-Premise Target string [Not Used]
Not used for API Sources
CMS Instance string [Do Not Populate]
This field should not be populated for Inbound or Outbound API External Source Configurations.
Outbound External Source Best Practices
Name string [required]
A descriptive title that identifies where the data is flowing. This value helps differentiate one outbound source from another in the system.
Note: Each facility can have only one defined outbound source. Ensure the name clearly reflects the destination or purpose of the data flow.
Example: "Production Custom Data Outbound to North Facility"
ID string [required]
A unique identifier for the outbound source. This ID is used in API payloads to identify the specific source system (e.g., in the externalSource field). The ID should be concise, system-friendly, and follow a consistent naming convention across integrations.
There must be a unique ID for each outbound source, and it must match what is configured in the destination system to ensure proper routing and traceability.
Example: "NorthFacilityCDIS" or "CMSOutbound01"
Description string [optional]
Provides additional context about the outbound source’s purpose or function. This field is helpful for internal tracking, configuration clarity, and future maintenance. Use it to describe what the source is intended for, especially when multiple integrations are in use.
Example: "Outbound source used for transmitting production data to North Facility"
Category string [required]
Defines the category this outbound source belongs to. This value helps classify the integration and ensures correct routing.
Example: "Scheduling", “Ordering”, “StaffAssignment”, “RTLS”
Inbound Message Forwarding URL string [Not Used]
Not used for outbound API sources. Leave this field blank.
On-Premise Target string [Not Used]
Not used for outbound API sources. This field should remain unpopulated unless explicitly required by your implementation team.
CMS Instance string [Do Not Populate]
This field should not be populated for Inbound or Outbound API External Source Configurations.