Connector Profiles

A connector profile identifies the authorized endpoint and credential context that an integration definition will use. The Connector Administrator records its organization, code, effective dates and policy reference. That gives the Integration Owner a specific profile to select when drafting a pipeline. A profile can be inactive without erasing the definitions and history already associated with it.

Begin with the actual organizations whose systems will exchange records. Decide who maintains each endpoint and when a changed credential or endpoint should take effect. The profile record is where that administrative choice becomes visible to the team. The source and destination systems still need their own connection details and authorization during setup.

• Organization first. Each profile belongs to an organization, so a similarly named endpoint in another organization remains distinct.
• Dated authority. Effective dates and the active flag help the administrator review which profile is intended for a scheduled definition.
• Mapping context. Field mappings refer to a profile and carry their own version and effective date for review.

The Integration Owner selects a profile on the definition. That link lets a reviewer move from the proposed work to the endpoint context and its field rules. A profile is a shared configuration record; changing it deserves a fresh look at every revision that relies on it.

Agree a naming convention for organization and profile codes, who may change endpoint credentials, and how policy references are recorded. Write down the source and destination field meanings before entering transform rules. For each mapping version, decide when it takes effect and which owner will request validation. Keep attachment evidence beside the integration definition when a reviewer needs a signed mapping decision or a sample delivery result.

Treat a change in endpoint identity or field meaning as an operational change. The Connector Administrator and Integration Owner should review the affected schedule and mapping version together before enabling a revised definition. This avoids a profile that looks current while a pending revision still describes an older contract.

Suppose an organization changes the endpoint that receives customer updates. The Connector Administrator creates or updates the profile with the new effective date and records the policy reference. They review the mappings that point to the profile, checking the source field, target field, types and transform rule. The Integration Owner then drafts the integration revision against that profile and identifies the intended mapping version.

The Independent Reviewer should be able to open the pending decision, follow it back to the definition, and inspect the mapping context. If the version is wrong, they return the decision with a reason. The owner corrects the revision and validates it again before the next synchronization. The earlier run and review stay available for an audit of what changed.

• Active Connector Profiles — Profiles for endpoint administration, including the organization and effective dates.
• Mapping Rules — Field transforms grouped around the profile selected for a definition.

Continue to validate the mapping and review the revision. The data model shows how the profile and mapping records join the definition.