Skip to main content
    Enterprise Integration, API & Automation Platform
    iShield Link logo

    iShield Link

    Connect Your Enterprise. Govern Every Interaction.

    Enterprise integration is no longer only about moving information between applications.

    Modern organizations must connect business systems, APIs, events, data services, operational environments and AI-enabled workflows while maintaining security, visibility and control.

    iShield Link provides a governed integration foundation for connecting enterprise capabilities and coordinating the interactions between them.

    Integration that connects. Governance that gives control.

    Overview

    Integration as a governed enterprise layer

    iShield Link sits between enterprise applications, partners, data services, operational systems and AI-enabled services — so the interactions between them are designed, controlled and observed in one place.

    Business value
    Connect existing investments with new digital capabilities, and reuse each connection instead of rebuilding it.
    Technical value
    One governed layer for interfaces, mediation, events, orchestration and the policies applied to them.
    Operational value
    Integration services that are visible, versioned and recoverable by the team that runs them.
    Platform architecture

    The Governed Interaction Path

    Follow one enterprise interaction through Link: a request enters through a managed interface, passes a policy check, is mediated and published as an event, drives a workflow and reaches its target — with evidence and an operations view at every step, and a defined path when delivery fails.

    • System
    • Interface
    • Policy check
    • Integration service
    • Event
    • Failure path
    • Evidence
    • Observability
    1. 01 SystemApplications & partners

      Source application

      A business application, partner or service starts an interaction — for example, an order, a case update or a data request.

      Who acts, controls and evidence
      Who acts
      The calling application, under its owner's credentials
      Evidence
      Caller identity on the request
    2. 02 InterfaceInterfaces & events

      Managed API call

      The request arrives at a published interface with an agreed contract instead of a direct connection into the target system.

      Who acts, controls and evidence
      Who acts
      API owner defines the contract
      Control
      Contract, version and consumer registration
      Evidence
      Call record per consumer
    3. 03 Policy checkControl & operations

      Access & policy check

      Who is calling, what they may do and any limits that apply are decided before the request goes further.

      Who acts, controls and evidence
      Decided by
      Rules set by security and governance leads
      Control
      Roles, attributes, rate limits and approval gates
      Evidence
      Decision with its reason
      If it fails
      A refused request returns a clear error and the refusal is recorded.
    4. 04 Integration serviceIntegration services

      Mediate & map

      The request is routed and its data mapped and validated into the form each receiving system expects.

      Who acts, controls and evidence
      Who acts
      Integration developer maintains routes and mappings
      Control
      Versioned flows and mapping rules
      Evidence
      Mapping and lineage records
      If it fails
      A record that fails validation is held with the reason instead of reaching the target.
    5. 05 EventInterfaces & events

      Business event

      What happened is published once as a business event, so every system that needs it can react without its own connection.

      Who acts, controls and evidence
      Who acts
      Event owner defines the event and its schema
      Control
      Publish and subscribe rights per channel; schema checks
      Evidence
      Event history for replay
    6. 06 Integration serviceIntegration services

      Orchestrated workflow

      Multi-step work across systems runs in order, pausing for a person where policy requires an approval.

      Who acts, controls and evidence
      Who acts
      Process owner defines steps and approvals
      Control
      Approval steps and service-level targets
      Evidence
      Workflow instance history

      07 Failure path

      Delivery fails

      If a target rejects or cannot receive the exchange, it is retried, replayed or held for review according to the configured rules — not lost silently.

      Who acts: Integration operations

    7. 08 SystemApplications & partners

      Target systems updated

      The receiving systems — which can include other iShield platforms — apply the change in their own records. Each system of record stays where it is.

      Who acts, controls and evidence
      Who acts
      Each system's owner
      Evidence
      Acknowledgement of delivery
    8. 09 EvidenceControl & operations

      Trace & evidence

      Calls, decisions, mappings, events and failures leave records that teams can follow end to end for investigation and review.

      Who acts, controls and evidence
      Who acts
      Integration operations · auditors review
      Evidence
      Trace across steps; decision and change records
    9. 10 ObservabilityControl & operations

      Operations view

      Health, delays, failures and dependencies of each integration service are visible to the team that runs it.

      Who acts, controls and evidence
      Who acts
      Integration operations
      Control
      Alert rules against agreed targets
      Evidence
      Health and alert history
    Illustration of a governed integration pattern — not a product screen. Which steps apply, and how, depends on the integration pattern and how it is implemented and configured.
    Capabilities

    From disconnected systems to coordinated enterprise capabilities

    01

    API Connectivity & Management

    Expose, connect and manage application capabilities through governed API interfaces and integration services.

    Support structured interactions between internal platforms, external applications and enterprise services.

    02

    Application & Data Integration

    Connect information and business processes across different systems through integration patterns, transformation and coordinated data exchange.

    03

    Events & Orchestration

    Support event-driven interactions and orchestrated workflows that connect activities across enterprise applications and operational processes.

    04

    Integration Operations

    Bring visibility, monitoring and operational management to integration services so teams can investigate failures, understand dependencies and maintain service continuity.

    05

    Security & Governance

    Apply appropriate access, policy and control mechanisms to integration interactions, supporting accountable and manageable enterprise connectivity.

    06

    AI-Enabled Integration

    Provide an architectural foundation for connecting AI-enabled services and enterprise workflows through governed interfaces, subject to the controls and capabilities implemented for each integration pattern.

    Integration lifecycle

    Integration is an enterprise lifecycle

    Design → Connect → Transform → Orchestrate → Secure → Observe → Improve

    This conceptual lifecycle helps explain how integration capabilities move from design into controlled enterprise operation.

    It is not a claim that each stage is a separate product module.

    1. 1Stage

      Design

      Define the interface, event or flow and agree its contract.

      Who: Enterprise architects · integration team

    2. 2Stage

      Connect

      Configure managed connections to the systems involved.

      Who: Integration team · system owners

    3. 3Stage

      Transform

      Map, validate and enrich data between systems.

      Who: Integration developers · data owners

    4. 4Stage

      Orchestrate

      Coordinate multi-step processes and the approvals they need.

      Who: Process owners

    5. 5Stage

      Secure

      Apply access, policy, tenancy and AI-use rules.

      Who: Security and governance leads

    6. 6Stage

      Observe

      Watch health, failures and dependencies in operation.

      Who: Integration operations

    7. 7Stage

      Improve

      Release changes through controlled, reversible versions.

      Who: Integration team · release approvers

    Modules

    Twelve integration modules

    The existing Link module inventory, organised by architectural plane. Each module shows its own pattern, controls, failure handling and cross-platform boundary.

    Interfaces & connectivity · Where systems, partners and devices meet Link.

    API Gateway

    Expose, govern, and secure APIs across internal and partner ecosystems.

    The managed front door for enterprise capabilities: one place to publish an interface, decide who may call it and see how it is used.

    1. 01

      Consumer calls

      An application or partner calls a published API.

    2. 02

      Identify

      The caller's credentials and scope are checked.

    3. 03

      Apply policy

      Rate limits and access rules are applied.

    4. 04

      Route

      The request goes to the right backend and version.

    5. 05

      Record

      Usage and errors are recorded for operations.

    Enterprise challenges

    • Interfaces published by each team in its own way
    • Partner access granted case by case
    • No shared view of who calls what

    Capabilities

    • Publish internal and partner APIs from a managed catalogue
    • Route requests to the right backend service and version
    • Apply authentication, authorisation and rate limits at the boundary
    • Version interfaces and retire old versions in a planned way

    Patterns and use cases

    • Expose a system of record to internal teams through a stable contract
    • Give partners scoped access to selected services
    • Put a legacy service behind a modern interface without changing it

    Architectural components

    • API catalogue and contracts
    • Gateway runtime and routing rules
    • Consumer applications and credentials
    • Usage and error records

    Roles and permissions

    • API owner: Defines the contract and who may use it
    • Integration team: Publishes, versions and routes the API
    • Security team: Sets authentication and access rules

    Governance and security

    • Access is granted per consumer and per scope
    • Changes to published contracts follow the integration lifecycle
    • Credentials can be rotated or revoked centrally

    Failures and recovery

    • A backend is unavailable: The caller receives a controlled error and the failure is visible to operations.
    • A consumer exceeds its limits: Requests are throttled according to the policy set for that consumer.

    Monitoring and observability

    • Calls, latency and errors per API and consumer
    • Version usage, to plan retirement

    Standards context

    • OpenAPI: Reference format for describing API contracts.
    • OAuth 2.0 and OpenID Connect: Common patterns for delegated authorisation and sign-in.
    • OWASP API Security Top 10: Reference list of API risks used to review design and policy.

    Cross-platform

    Other iShield platforms can expose or consume services through managed APIs; what is exposed depends on how each platform is implemented and configured.

    Business outcomes

    • Reusable interfaces instead of one-off connections
    • A clear record of who uses which service

    See also in the module index:API Management & Developer PortalUsage Metering & Rate Limits

    Connector Hub

    Reusable connectors for SaaS, databases, ERPs, and message buses.

    A shared library of managed connections, so each system is connected once and reused by every integration that needs it.

    1. 01

      Select

      Choose a connector for the target system.

    2. 02

      Configure

      Set the connection and its credentials.

    3. 03

      Test

      Check the connection in a non-production environment.

    4. 04

      Reuse

      Flows and APIs use the same managed connection.

    Enterprise challenges

    • The same system connected several times by different teams
    • Credentials scattered across scripts
    • Connection changes that break unknown integrations

    Capabilities

    • Configure reusable connectors for applications, databases, files and message systems
    • Manage connection credentials centrally
    • Version connectors and see where each is used

    Patterns and use cases

    • Connect a business application once and reuse it across flows
    • Swap the system behind a connector with limited change to flows
    • Connect identity and privileged-access tools for governed integrations

    Architectural components

    • Connector definitions
    • Connection credentials
    • Usage map of flows using each connector

    Roles and permissions

    • Integration team: Configures and maintains connectors
    • System owners: Approve access to their systems

    Governance and security

    • Credentials are held centrally rather than in individual flows
    • Connector changes are visible to every flow that uses them

    Failures and recovery

    • A connected system changes or becomes unavailable: Affected flows are identifiable and the failure is visible to operations.

    Monitoring and observability

    • Connection health per connector
    • Which flows depend on each connector

    Standards context

    • ISO/IEC 27001 and 27002: Security-management guidance relevant to credential and access handling.

    Cross-platform

    Connectors can serve iShield platforms and existing systems alike; available connectors depend on the implementation.

    Business outcomes

    • Connections built once and reused
    • Credentials managed in one place

    OT Bridge

    Industrial protocol connectivity — OPC-UA, MQTT, SCADA, DCS.

    Brings operational-technology data into enterprise processes through a controlled boundary, keeping industrial networks separate from business systems.

    1. 01

      Collect

      Readings or events are collected at the site.

    2. 02

      Check boundary

      Zone and direction rules are applied.

    3. 03

      Normalise

      Data is converted to an enterprise format.

    4. 04

      Publish

      Enterprise consumers receive the data.

    Enterprise challenges

    • Plant data trapped in operational systems
    • Direct connections that weaken network separation
    • Different protocols on every site

    Capabilities

    • Read data from industrial protocols and systems where supported
    • Publish operational events to enterprise consumers
    • Apply zone and direction rules at the boundary

    Patterns and use cases

    • Equipment readings feeding maintenance and quality processes
    • Production events informing planning in the ERP
    • Site data shared with central analytics

    Architectural components

    • Site connectors
    • Protocol adapters
    • Boundary rules
    • Operational event channels

    Roles and permissions

    • OT engineer: Configures site connections and boundary rules
    • Enterprise consumers: Use the published operational data

    Governance and security

    • Data direction and zones are set per site
    • Changes to site connections follow the integration lifecycle

    Failures and recovery

    • A site connection drops: The gap is visible to operations and data can be caught up where buffering is configured.

    Monitoring and observability

    • Connection status per site
    • Data flow from each site

    Standards context

    • NIST Cybersecurity Framework: Reference for identifying and protecting operational boundaries.

    Cross-platform

    Operational data can inform maintenance, quality and planning on other iShield platforms where implemented and configured.

    Business outcomes

    • Operational data in enterprise processes without direct network links
    • One controlled boundary per site

    Integration services · Where messages are routed, mapped, published and orchestrated.

    ESB & Mediation

    Route, transform, and orchestrate messages across enterprise systems.

    The mediation layer between systems that do not speak the same language, so each connection does not have to be rebuilt point to point.

    1. 01

      Receive

      A message arrives from a connected system.

    2. 02

      Inspect

      Its type, source and content are read.

    3. 03

      Transform

      It is converted into the receiving format.

    4. 04

      Route

      It is sent to one or more destinations.

    5. 05

      Confirm

      Delivery is acknowledged or the failure is handled.

    Enterprise challenges

    • Point-to-point connections that multiply with every new system
    • Message formats that differ between applications
    • Routing logic hidden inside individual applications

    Capabilities

    • Route messages by content, source or destination
    • Transform messages between formats
    • Bridge synchronous and asynchronous exchanges
    • Handle partner and business-to-business message exchange where configured

    Patterns and use cases

    • Hub-style mediation between ERP, CRM and service platforms
    • Content-based routing of orders, cases or documents
    • Protocol bridging for older applications

    Architectural components

    • Mediation flows
    • Routing rules
    • Transformation steps
    • Endpoints for each connected system

    Roles and permissions

    • Integration developer: Builds mediation flows and routing rules
    • Application owners: Agree the message contracts for their systems

    Governance and security

    • Flows are versioned and released through the integration lifecycle
    • Access to each endpoint uses managed credentials

    Failures and recovery

    • A destination rejects a message: The message is held for retry or review instead of being lost silently.
    • A message cannot be transformed: It is set aside with the reason, for the integration team to correct.

    Monitoring and observability

    • Message flow status and failures per route
    • Messages held for retry or review

    Standards context

    • ISO/IEC 20000: Service-management reference for operating integration services.

    Cross-platform

    Mediation can connect iShield platforms with each other and with existing systems; each exchange depends on implementation and configuration.

    Business outcomes

    • Fewer connections to maintain as systems change
    • Routing rules that are visible and owned

    See also in the module index:iPaaS (Flows, Connectors)B2B / EDI (EDIFACT, X12, AS2, PEPPOL)

    Event Bus

    Pub/sub backbone with replay, ordering, and event-driven workflows.

    The backbone for business events: systems publish what happened once, and every interested system can react without a direct connection.

    1. 01

      Publish

      A producer publishes a business event.

    2. 02

      Check schema

      The event is checked against its agreed definition.

    3. 03

      Distribute

      Subscribers receive the event.

    4. 04

      React

      Consumers update records or start workflows.

    5. 05

      Replay

      A consumer can replay events it missed.

    Enterprise challenges

    • Systems polling each other for changes
    • Business events that are lost when a consumer is offline
    • No shared definition of what an event contains

    Capabilities

    • Publish and subscribe to business events
    • Keep events in order where the use case requires it
    • Replay events to a consumer that needs to catch up
    • Trigger workflows from events

    Patterns and use cases

    • Order placed, case closed or asset changed — published once, consumed by many
    • Event-driven updates between IT and operational systems
    • Catch-up after a planned outage of a consuming system

    Architectural components

    • Topics or channels
    • Event schemas
    • Producers and subscribers
    • Replay and retention settings

    Roles and permissions

    • Event owner: Defines the event and its schema
    • Consuming teams: Subscribe and handle the events they need

    Governance and security

    • Who may publish or subscribe is controlled per channel
    • Schema changes follow an agreed versioning approach

    Failures and recovery

    • A consumer cannot process an event: The event is kept for retry or replay according to the retention settings.
    • An event does not match its schema: It is rejected or quarantined and the producer is informed.

    Monitoring and observability

    • Event flow and consumer lag per channel
    • Rejected and replayed events

    Standards context

    • AsyncAPI: Reference format for describing event-driven interfaces and channels.

    Cross-platform

    iShield platforms can publish or consume business events through Link where this is implemented and configured.

    Business outcomes

    • Systems that react to change instead of polling for it
    • Recovery from consumer outages without re-sending by hand

    See also in the module index:Event Bus (Kafka / AMQP-compatible)Schema Registry & Replay

    Workflow Engine

    Multi-step orchestration with approvals and SLA enforcement.

    Coordinates processes that span several systems and people, so a multi-step exchange runs in the right order and stops where a human must decide.

    1. 01

      Start

      A request or event starts the workflow.

    2. 02

      Call systems

      Each step calls the systems involved.

    3. 03

      Approve

      A person approves where policy requires it.

    4. 04

      Track time

      Progress is measured against its target.

    5. 05

      Complete

      The outcome is recorded with its history.

    Enterprise challenges

    • Cross-system processes held together by email and spreadsheets
    • Approvals that happen outside any record
    • No owner when a multi-step process stalls

    Capabilities

    • Orchestrate steps across several systems
    • Insert human approvals where policy requires them
    • Track time against agreed service levels
    • Route exceptions to the right team

    Patterns and use cases

    • Onboarding a customer, supplier or employee across several systems
    • Approval-gated changes to master data
    • Compensating steps when part of a process fails

    Architectural components

    • Workflow definitions
    • Approval steps
    • Timers and service-level targets
    • Exception queues

    Roles and permissions

    • Process owner: Defines steps, approvals and targets
    • Approvers: Decide on gated steps
    • Operations team: Resolves stalled or failed instances

    Governance and security

    • Approvals are recorded against the workflow instance
    • Workflow definitions are versioned and released under control

    Failures and recovery

    • A step fails: The workflow pauses, retries or runs compensating steps as defined.
    • A target time is at risk: The responsible team is alerted.

    Monitoring and observability

    • Running, waiting and failed instances
    • Time against target per workflow

    AI and automation

    AI-assisted steps can be included where they run through governed interfaces and a person approves sensitive actions.

    Standards context

    • ISO/IEC 20000: Service-management reference for agreed service levels.

    Cross-platform

    Workflows can include steps on other iShield platforms; each depends on how those platforms are implemented and configured.

    Business outcomes

    • Cross-system processes with a single owner and history
    • Approvals that leave a record

    See also in the module index:Approval Broker

    Data Mapper

    Schema mapping, enrichment, validation, and lineage tracking.

    Makes data exchanged between systems mean the same thing on both sides, and shows where each field came from.

    1. 01

      Read source

      Source fields and their schema are read.

    2. 02

      Map

      Fields are mapped to the target schema.

    3. 03

      Validate

      Values are checked against rules.

    4. 04

      Enrich

      Reference data is added where defined.

    5. 05

      Trace

      Lineage is recorded for each mapped value.

    Enterprise challenges

    • The same customer, product or asset described differently in each system
    • Data quality problems discovered downstream
    • No record of how a value was derived

    Capabilities

    • Map fields between source and target schemas
    • Enrich and validate data as it moves
    • Record lineage from source to target
    • Version mappings with their integrations

    Patterns and use cases

    • Master-data synchronisation between ERP, CRM and service platforms
    • Normalising records from several sources
    • Validating partner data before it reaches a system of record

    Architectural components

    • Source and target schemas
    • Mapping rules
    • Validation rules
    • Lineage records

    Roles and permissions

    • Data owner: Defines meaning and quality rules
    • Integration developer: Builds and maintains mappings

    Governance and security

    • Mapping changes are versioned and released under control
    • Sensitive fields can be masked or excluded where configured

    Failures and recovery

    • A record fails validation: It is held with the reason instead of entering the target system.

    Monitoring and observability

    • Validation failures per mapping
    • Lineage from source to target

    Standards context

    • ISO/IEC 27701: Privacy-management reference where mapped data includes personal data.

    Cross-platform

    Mappings can align records between iShield platforms and other systems; the systems of record stay where they are.

    Business outcomes

    • Consistent records across connected systems
    • Traceable data for audit and investigation

    Control plane · Where access, policy, AI use and tenancy are decided.

    AI Integration

    Governed access to LLMs and AI agents with policy controls.

    Connects AI-enabled services to enterprise systems through governed interfaces, so AI use follows the same access and evidence rules as any other integration.

    1. 01

      Request

      An AI service requests data or an action.

    2. 02

      Check scope

      Its identity, tools and data scope are checked.

    3. 03

      Approve

      A person approves sensitive actions.

    4. 04

      Execute

      The call runs through an approved interface.

    5. 05

      Record

      The request and outcome are recorded.

    Enterprise challenges

    • AI tools connected directly to sensitive systems
    • No record of what an AI service accessed or triggered
    • Different rules for each AI provider

    Capabilities

    • Route AI requests through managed interfaces
    • Limit which tools and actions an agent may use
    • Require human approval for sensitive actions where configured
    • Record AI-initiated requests and outcomes

    Patterns and use cases

    • An assistant that reads approved records through managed APIs
    • An agent that proposes actions for a person to approve
    • Switching AI providers behind a stable interface

    Architectural components

    • AI provider connections
    • Tool and action allow-lists
    • Approval steps
    • AI activity records

    Roles and permissions

    • AI product owner: Defines what the AI service may do
    • Security and data owners: Set access and data rules
    • Business approvers: Approve sensitive AI-proposed actions

    Governance and security

    • AI services use the same identity and policy controls as other consumers
    • Sensitive actions can require human approval

    Failures and recovery

    • An AI request falls outside its allowed scope: It is blocked and recorded for review.

    Monitoring and observability

    • AI-initiated requests, blocked actions and approvals

    AI and automation

    This module is the integration layer for AI-enabled services. Decisions on sensitive actions stay with people where approval is configured.

    Standards context

    • ISO/IEC 42001: AI management-system reference for governing AI use.
    • OWASP API Security Top 10: Reference for risks at the interfaces AI services call.

    Cross-platform

    AI-enabled features on other iShield platforms can reach enterprise services through Link where this is implemented and configured.

    Business outcomes

    • AI use that follows enterprise access rules
    • A record of what AI services accessed and triggered

    Policy Engine

    RBAC, ABAC, segregation of duties, and approval gating.

    One place to decide who and what may use each integration, applied consistently at every interface, flow and event channel.

    1. 01

      Request

      A caller, flow or agent asks to act.

    2. 02

      Evaluate

      Roles, attributes and rules are evaluated.

    3. 03

      Gate

      An approval is required where policy says so.

    4. 04

      Decide

      The action is allowed or refused.

    5. 05

      Record

      The decision is recorded with its reason.

    Enterprise challenges

    • Access rules re-implemented in every integration
    • Segregation of duties checked after the fact
    • Approvals without a link to the change they approved

    Capabilities

    • Role- and attribute-based access decisions
    • Segregation-of-duties checks
    • Approval gates for sensitive changes or actions
    • Consistent policy across APIs, flows and events

    Patterns and use cases

    • A partner allowed to read but not to change
    • A sensitive integration change that needs a second approver
    • Data rules that depend on the record's classification

    Architectural components

    • Policy definitions
    • Decision points at interfaces and flows
    • Approval rules
    • Decision records

    Roles and permissions

    • Security and governance leads: Define policy and approval rules
    • Approvers: Decide on gated actions

    Governance and security

    • Policies are versioned and changes are recorded
    • Decisions are recorded for review

    Failures and recovery

    • A request is refused: The caller receives a clear refusal and the decision is recorded.

    Monitoring and observability

    • Allowed and refused decisions
    • Pending approvals

    Standards context

    • ISO/IEC 27001 and 27002: Access-control and segregation guidance.
    • NIST Cybersecurity Framework: Reference for protecting access to services.

    Cross-platform

    Policy decisions apply to integrations that involve any iShield platform; the platforms keep their own internal permissions.

    Business outcomes

    • The same rule applied everywhere an integration runs
    • Decisions that can be reviewed later

    Tenant Console

    Multi-tenant isolation, quotas, and provider workspaces.

    Separates integration estates by tenant, business unit or customer, each with its own policies, quotas and administration.

    1. 01

      Provision

      A tenant workspace is created.

    2. 02

      Set policy

      Policies and quotas are assigned.

    3. 03

      Operate

      Integrations run within the tenant's boundary.

    4. 04

      Report

      Usage is attributed to the tenant.

    Enterprise challenges

    • Business units sharing one integration estate without boundaries
    • Service providers managing many customers by hand
    • Usage that cannot be attributed

    Capabilities

    • Separate workspaces per tenant
    • Per-tenant policies and quotas
    • Provider administration across tenants

    Patterns and use cases

    • A group with several operating companies
    • A service provider running integrations for its customers
    • Separate environments for regulated business units

    Architectural components

    • Tenant workspaces
    • Tenant policies and quotas
    • Provider administration

    Roles and permissions

    • Platform administrator: Creates tenants and sets policies
    • Tenant administrators: Manage their own integrations

    Governance and security

    • Administration rights are scoped per tenant
    • Tenant changes are recorded

    Failures and recovery

    • A tenant reaches its quota: Its usage is limited according to its policy, without affecting other tenants.

    Monitoring and observability

    • Usage and health per tenant

    Standards context

    • ISO/IEC 27001 and 27002: Guidance on separating environments and access.

    Cross-platform

    Tenant usage can be passed to billing in iShield One where implemented and configured.

    Business outcomes

    • Clear boundaries between business units or customers
    • Usage that can be attributed

    Operations · Where integration services are watched, released and recovered.

    Runtime Monitor

    Live telemetry, retries, SLA alerts, and root cause traces.

    The operations view of every integration service, so teams can see failures, understand dependencies and restore service.

    1. 01

      Observe

      Telemetry is collected from every step.

    2. 02

      Detect

      A failure or delay is detected.

    3. 03

      Alert

      The responsible team is alerted.

    4. 04

      Trace

      The exchange is traced across steps.

    5. 05

      Recover

      The team retries, replays or corrects it.

    Enterprise challenges

    • Failures found by the business before the integration team
    • No end-to-end trace across systems
    • Retries that hide recurring problems

    Capabilities

    • Health and status of integration services
    • Traces that follow an exchange across steps
    • Retry visibility and failure queues
    • Alerts against agreed targets

    Patterns and use cases

    • Investigating a failed order exchange across several systems
    • Spotting a consumer that keeps falling behind
    • Reporting service levels for integration services

    Architectural components

    • Telemetry collection
    • Traces and logs
    • Alert rules
    • Failure and retry queues

    Roles and permissions

    • Integration operations: Watches health and resolves failures
    • Service owners: Agree targets and receive reports

    Governance and security

    • Access to logs and traces is controlled
    • Operational records support incident review

    Failures and recovery

    • Alerts are missed: Failure queues keep the affected exchanges until someone acts on them.

    Monitoring and observability

    • This module is the observability layer for the others

    Standards context

    • ISO/IEC 20000: Service-management reference for incident and service-level practice.

    Cross-platform

    Integration incidents can be handled in iShield Nexus where it is used for service operations; this depends on implementation and configuration.

    Business outcomes

    • Failures seen and owned by the integration team
    • Faster understanding of where an exchange stopped

    See also in the module index:Per-tenant Audit StreamFinOps Anomaly Agent

    Lifecycle Manager

    Versioning, blue-green deploys, canary, rollback, audit.

    Moves integrations from design to production through controlled stages, so every change is versioned, approved and reversible.

    1. 01

      Draft

      A new version is designed.

    2. 02

      Test

      It is validated outside production.

    3. 03

      Approve

      The release is approved.

    4. 04

      Release

      It is released, gradually where configured.

    5. 05

      Roll back

      It can be reverted if problems appear.

    Enterprise challenges

    • Integrations changed directly in production
    • No way back after a faulty release
    • Changes without an owner or approval

    Capabilities

    • Version integrations, APIs and mappings
    • Promote through environments with approvals
    • Release gradually and roll back where configured
    • Keep a history of every change

    Patterns and use cases

    • Draft, test, approve and release a new flow version
    • Release a change to part of the traffic first
    • Roll back a faulty mapping

    Architectural components

    • Versions and environments
    • Release approvals
    • Release strategies
    • Change history

    Roles and permissions

    • Integration developer: Prepares and tests versions
    • Release approver: Approves production changes

    Governance and security

    • Production changes require approval
    • Every release and rollback is recorded

    Failures and recovery

    • A release causes errors: It can be rolled back to the previous version.

    Monitoring and observability

    • Which version runs where
    • Release and rollback history

    Standards context

    • ISO/IEC 20000: Change-management reference.
    • ISO/IEC 27001 and 27002: Change-control guidance.

    Cross-platform

    Changes to integrations with other iShield platforms follow the same lifecycle.

    Business outcomes

    • No untracked production changes
    • A known way back from every release

    See also in the module index:Drift Remediator

    Use cases

    Connect applications, workflows, data and AI

    Enterprise applications

    Enable business systems to exchange information and coordinate processes across functional boundaries.

    APIs and digital services

    Make enterprise capabilities accessible through managed interfaces and reusable integration patterns.

    Events and workflows

    Coordinate event-driven interactions and multi-system processes with appropriate operational controls.

    Data services

    Support controlled movement and transformation of information between relevant enterprise systems.

    AI-enabled services

    Connect AI-assisted applications and agents to enterprise services through governed integration patterns, with access and oversight appropriate to the use case.

    Enterprise use cases

    18 integration scenarios across business, technology, industrial and AI environments. Choose a category, then open a scenario to see its integration flow and the Link modules involved.

    18 use cases shown

    • Sales & Customer Experience

      Business challenge

      A won opportunity has to become an order, a delivery and an invoice in other systems.

      Integration scenario

      Managed APIs and mappings carry the order across; a workflow tracks each step and holds failures for review.

      Enterprise systems

      • CRM

      Target applications

      • Order and delivery
      • Invoicing
      Illustration of an integration pattern — not a product screen. Which systems take part, and how, depends on each implementation and configuration.
    • Cybersecurity & Industrial Operations

      Equipment, asset or service events need to start work in business systems.

    • Finance & Enterprise Operations

      Purchasing processes span procurement platforms, supplier networks, inventory management, ERP and financial systems. Disconnected transactions create delays, inconsistent records and reconciliation problems.

    • Finance & Enterprise Operations

      Finance teams consolidate transactions and balances from multiple ERP instances, banks, subsidiaries and operational systems.

    • Supply Chain & Workforce

      Inventory availability, warehouse activity and customer orders must remain coordinated across commerce, ERP, warehouse and logistics systems.

    • Supply Chain & Workforce

      Hiring, transfers and departures require coordinated updates across HR, identity management, IT service management and enterprise applications.

    • Cybersecurity & Industrial Operations

      Security incidents involve signals and response activities distributed across SIEM, SOAR, EDR, NDR, ticketing and enterprise service platforms.

    • Cybersecurity & Industrial Operations

      Industrial equipment, operational technology and enterprise business systems often operate across different protocols, security zones and availability requirements.

    • Sales & Customer Experience

      Customer information is fragmented across CRM, ERP, commerce, contact center and service platforms.

    • Data, Cloud & Governance

      Compliance and audit activities require information from finance, HR, cybersecurity, procurement and operational systems.

    • Data, Cloud & Governance

      Enterprises must connect legacy applications, on-premises environments, cloud platforms and SaaS services without creating unmanageable point-to-point dependencies.

    • Data, Cloud & Governance

      Analytics and data platforms depend on timely information from transactional applications, operational systems and external sources.

    • Finance & Enterprise Operations

      Vendor governance depends on external cyber ratings, financial intelligence, corporate information and internal procurement records.

    • AI & Intelligent Automation

      Enterprise AI applications need controlled access to business systems and actions without bypassing authorization, accountability or operational controls.

    Integration estate

    The systems an integration layer has to reach

    Typical systems in an enterprise integration estate. Connectivity to any named product depends on the connector or interface used in each implementation.

    • ERP & core business systems

      SAP / Oracle / Dynamics / iShield One

    • CRM & engagement platforms

      Salesforce / HubSpot / Dynamics / Oracle CX / iShield Connect

    • ITSM & workflow systems

      ServiceNow / Jira / Remedy / iShield Nexus

    • HRIS & people platforms

      Workday / SuccessFactors / iShield One

    • Cloud services & data

      AWS / Azure / GCP

    • AI & agentic services

      OpenAI / Anthropic / LLMs

    • OT, IIoT & industrial control

      SCADA / DCS / MES / OPC-UA

    • Legacy & custom APIs

      Mainframe / SOAP / REST / GraphQL / iShield Link

    Unclear how our ecosystem fits your stack?

    Request a complimentary integration assessment. Our architects will map your current systems to the iShield product suite and recommend the optimal connectivity path.

    Request Integration Assessment
    Security & governance

    Control applied where integrations run

    Access, policy and approval rules are applied at the interfaces, flows and event channels themselves — not left to each connected application.

    Decide who and what may connect

    Role- and attribute-based access, consumer registration and scoped credentials for applications, partners and AI services.

    Gate the changes that matter

    Approval steps for sensitive actions and production releases, with segregation of duties where configured.

    Keep boundaries between estates

    Separate tenants, business units or sites, each with their own policies and quotas.

    Reference frameworks

    Standards and practices relevant to integration architecture and governance discussions. They are listed as context; this page makes no certification or conformity statement against them.

    Integration operations

    Run integration as an operated service

    Integration services are watched, recovered and changed by the team that owns them, with the evidence to show what happened.

    See

    • Health and status of each integration service
    • Failures, delays and messages held for review
    • Which flows depend on which connections

    Act

    • Retry, replay or correct a failed exchange
    • Roll back a faulty release to its previous version
    • Pause a consumer or partner within its policy

    Show

    • Policy decisions with their reasons
    • Change and release history
    • AI-initiated requests, approvals and blocked actions

    Operational outcomes

    • Fewer point-to-point connections to maintain as systems change
    • Integration failures seen and owned by the team that runs them
    • Production changes that are versioned, approved and reversible
    • Access rules applied the same way at every interface
    • A record of who and what used each enterprise service
    Why Link

    Built for enterprise architecture and operational control

    For enterprise architects:

    Establish clearer integration patterns and more coherent connectivity across the technology landscape.

    For integration teams:

    Support the development, operation and maintenance of integration services through a coordinated platform approach.

    For security and governance leaders:

    Incorporate appropriate security, access and accountability requirements into integration design and operation.

    For digital transformation leaders:

    Connect existing investments with new digital capabilities without requiring every system to be replaced.

    Cross-platform boundaries

    Link connects. Each platform keeps its responsibility.

    Exchanges between iShield platforms depend on how they are implemented and configured.

    • iShield Link

      Integration and connectivity: interfaces, mediation, events, orchestration and the policies applied to them.

      Connects systems; does not become the system of record for the data it carries.

    • iShield Nexus

      Enterprise service and technology operations.

      Integration incidents and changes can be managed in Nexus where it is used.

      Explore iShield Nexus
    • iShield Connect

      CRM and customer engagement.

      Customer records stay in Connect; Link carries agreed exchanges with other systems.

      Explore iShield Connect
    • iShield One

      ERP and business transactions.

      Orders, postings and invoices stay in One; Link carries the exchanges around them.

      Explore iShield One
    • iShieldGRC

      Governance, risk, compliance and specialist controls.

      Control evidence and assessments stay in iShieldGRC; integration records can inform them.

      Explore iShieldGRC
    AI-enabled integration

    iShield Link in the AI era

    AI becomes more useful when it can interact appropriately with enterprise systems and processes.

    It also introduces new integration challenges involving permissions, sensitive information, tool execution, operational accountability and oversight.

    iShield Link's AI-era architecture addresses the integration layer of these challenges, connecting AI-enabled capabilities with enterprise services through governed interfaces.

    Explore the dedicated AI-era experience to understand the supported integration patterns and control capabilities.

    On the AI-era page

    • The AI Action Control Path
    • Ten pillars of governed AI enablement
    • Where people stay in charge
    • Capability map
    iShield Link in the AI Era
    Industries

    Built for Regulated and Complex Environments

    Where integration must be secure, auditable, controlled, and resilient.

    Energy & UtilitiesOil & GasGovernment & Public SectorFinancial ServicesHealthcareTelecommunicationsCritical InfrastructureTransportationManufacturing & Industry 4.0Mining & MetalsSmart Cities & UtilitiesLarge Enterprise GroupsRegulated Multinationals
    Deployment & Tenancy

    iShield Link runs the way your business requires

    SaaS by default

    Managed multi-tenant SaaS with continuous updates and zero infrastructure to operate.

    Hybrid when needed

    Control plane in iShield cloud, data plane in customer cloud (AWS, Azure, GCP, OCI).

    One architecture, every model

    SaaS, single-tenant cloud, hybrid and on-prem share the same code, APIs and upgrade path. No deployment lock-in.

    Deployment Architecture

    Control plane vs data plane — Link

    The same product, deployed three ways.

    Control Plane
    iShield-managed · Link services
    iShield Cloud
    • Orchestration & APIsTenant router, policy engine, AI gateway
    • Identity & RBACSSO, SCIM, JIT provisioning
    • Admin consoleTenant admin, audit, observability
    Data Plane
    iShield-managed
    • Tenant database
    • BYOK encryptionCustomer-managed KMS key wrap
    Control plane owner
    iShield
    Data plane owner
    iShield
    Network egress
    Managed inbound/outbound
    Upgrades
    Continuous, zero-downtime
    Best for
    Fastest time-to-value, global teams

    Same codebase, same APIs, same upgrade path across all three models — no deployment lock-in.

    Capability catalogue

    Explore iShield Link Capabilities

    Enterprise integration, governed connectivity and intelligent orchestration.

    iShield Link connects enterprise applications, data, partners and industrial systems through managed APIs, business events and integration flows. Policy, data-protection and access controls apply to each interaction as configured, and audit and lineage records keep the activity traceable. The catalogue also lists AI-enabled solution components that rely on Link for connectivity and governed data access; their business logic and decisions stay with the platform that owns each domain.

    Category

    Architectural role

    76 of 76 capabilities shown

    Integration & Connectivity (12)

    Connect applications, data sources, partners, identity services and industrial systems through reusable connectors and integration flows.

    • Link integration module

      Catalogue of reusable connectors for applications, databases and services, so integrations reuse managed connections instead of one-off code.

      Used in 1 solution

    • Link integration module

      Designs and runs integration flows that move and transform data between connected systems.

      Used in 1 solution

    • Link integration module

      Exchanges structured business documents with trading partners through B2B and EDI flows.

      Used in 1 solution

    • Link integration module

      Connects industrial equipment and plant systems to enterprise applications through the OT Bridge module.

      Used in 1 solution

    • Link integration module

      Connects industrial protocols and plant data historians to enterprise systems through the OT Bridge module.

      Used in 1 solution

    • Link integration module

      Runs integration workloads close to sites and equipment, where data is processed locally before it reaches central systems.

      Used in 1 solution

    • Cross-product solution component

      Aligns equipment and tag naming from different plant systems into consistent asset references.

      Used in 1 solution

    • Link integration module

      Connects to the organisation's identity provider so integrations and solution flows use existing workforce identities.

      Used in 1 solution

    • Link integration module

      Passes privileged-access requests from integration and identity flows to the organisation's privileged access management tool.

      Used in 1 solution

    • Link integration module

      Connects customer sign-up and sign-in journeys to external identity-verification services.

      Used in 1 solution

    • Link integration module

      Provides a federated view across connected data sources, so approved consumers can query data where it is held.

      Used in 1 solution

    • Shared platform service

      Describes the data products available through the data fabric so teams can discover and request them.

      Used in 1 solution

    API, Events & Orchestration (5)

    Publish and manage APIs, distribute business events, keep message contracts consistent and coordinate multi-step and AI-assisted interactions.

    • Link integration module

      Publishes, secures and documents APIs, and gives internal and partner developers a portal to discover and use them.

      Used in 1 solution

    • Link integration module

      Distributes business events between producers and consumers, so systems react to change without direct coupling.

      Used in 1 solution

    • Link integration module

      Keeps message and event contracts versioned and consistent, and allows recorded events to be replayed after a correction.

      Used in 1 solution

    • Link integration module

      Routes requests from applications and agents to approved AI model providers through one governed entry point.

      Used in 1 solution

    • Shared platform service

      Coordinates which tools an AI agent may call, what context it may keep and where a person must approve before an action proceeds.

      Used in 1 solution

    Governance, Policy & Trust (15)

    Policy, data-protection and access controls that integrations and AI-enabled components pass through, as configured for each implementation.

    • Shared platform service

      Evaluates policies written as code against requests and configuration changes, so rules are versioned and reviewable.

      Used in 1 solution

    • Shared platform service

      Applies policies that respect the separation of plant network zones when industrial data moves toward enterprise systems.

      Used in 1 solution

    • Shared platform service

      Masks or removes personal data from records moving through integration flows where policy requires it.

      Used in 2 solutions

    • Shared platform service

      Screens prompts and model responses against policy and removes personal data before it reaches an AI model.

      Used in 1 solution

    • Shared platform service

      Routes data and requests to the regions or environments permitted by residency policy.

      Used in 2 solutions

    • Shared platform service

      Applies the tenant-separation and region rules configured for each tenant of a multi-tenant service.

      Used in 1 solution

    • Cross-product solution component

      Requests time-limited access for a specific task and routes it for approval, instead of relying on standing access.

      Used in 1 solution

    • Cross-product solution component

      Collects access data from connected systems and routes periodic access reviews to the responsible reviewers.

      Used in 1 solution

    • Cross-product solution component

      Highlights combinations of access rights that conflict with segregation-of-duties rules, for review.

      Used in 1 solution

    • Cross-product solution component

      Passes risk and fraud signals into customer sign-in journeys, so additional verification can be requested where policy requires.

      Used in 1 solution

    • Shared platform service

      Controls which features each tenant or plan can use, based on its entitlements.

      Used in 1 solution

    • Shared platform service

      Routes proposed actions to the right people for approval and records the decision before anything proceeds.

      Used in 1 solution

    • Cross-product solution component

      Applies policy and approval checks to automated security playbook actions before they reach connected systems.

      Used in 1 solution

    Observability & Lifecycle (6)

    Audit, lineage, evaluation, usage and tenant-lifecycle capabilities that keep integrations and AI use traceable and operable.

    • Shared platform service

      Provides each tenant with its own stream of audit events for review and export.

      Used in 1 solution

    • Shared platform service

      Runs evaluation and adversarial test sets against AI components before and after changes.

      Used in 1 solution

    • Shared platform service

      Records where data came from and how it was transformed as it moves through integrations.

      Used in 2 solutions

    • Shared platform service

      Measures API and integration usage per tenant and applies the rate limits configured for each plan.

      Used in 1 solution

    • Shared platform service

      Coordinates provisioning, suspension and offboarding of tenants across connected services.

      Used in 1 solution

    • Cross-product solution component

      Detects configuration drift from the declared state and prepares corrective changes for approval.

      Used in 1 solution

    AI Agents & Cross-Product Solutions (38)

    Domain AI agents, copilots and solution components that combine Link with other iShield platforms. Link provides connectivity, governed data access and visibility; business logic and decisions stay with the owning platform and the people accountable for them.

    • Cross-product solution component

      Runs customer sign-up and sign-in journeys, including passwordless, social and multi-factor options as configured.

      Used in 1 solution

    • Domain AI agent or copilot

      Suggests categorisation, priority and likely assignment for new IT incidents, for the service desk to confirm.

      Used in 1 solution

    • Domain AI agent or copilot

      Estimates the risk of a proposed IT change from its context and history, to inform change review.

      Used in 1 solution

    • Domain AI agent or copilot

      Produces summaries of tickets, conversations and records for people to review.

      Used in 2 solutions

    • Domain AI agent or copilot

      Flags unusual patterns in operational telemetry for investigation.

      Used in 1 solution

    • Domain AI agent or copilot

      Correlates events and changes to suggest likely causes of an operational issue.

      Used in 1 solution

    • Domain AI agent or copilot

      Suggests the approved runbook that best matches an operational issue.

      Used in 1 solution

    • Domain AI agent or copilot

      Prepares remediation steps from approved runbooks; steps run only where configured and after the required approval.

      Used in 1 solution

    • Domain AI agent or copilot

      Flags unexpected changes in cloud spend for the teams responsible.

      Used in 1 solution

    • Domain AI agent or copilot

      Suggests how applications map to business capabilities, to support portfolio analysis.

      Used in 1 solution

    • Domain AI agent or copilot

      Summarises technical-debt indicators per application to inform portfolio decisions.

      Used in 1 solution

    • Domain AI agent or copilot

      Suggests a TIME disposition (tolerate, invest, migrate or eliminate) for each application, for portfolio owners to decide.

      Used in 1 solution

    • Domain AI agent or copilot

      Drafts audit narratives from collected evidence for auditors to review and edit.

      Used in 1 solution

    • Domain AI agent or copilot

      Gathers evidence from connected systems for the controls being assessed.

      Used in 1 solution

    • Domain AI agent or copilot

      Tracks regulatory updates and highlights those that may affect existing obligations.

      Used in 1 solution

    • Domain AI agent or copilot

      Suggests risk scores from connected data, for risk owners to review.

      Used in 1 solution

    • Domain AI agent or copilot

      Suggests grouping and priority for security alerts, for analysts to confirm.

      Used in 1 solution

    • Domain AI agent or copilot

      Ranks known vulnerabilities by likely exploitability, to help prioritise remediation work.

      Used in 1 solution

    • Domain AI agent or copilot

      Assembles related alerts, assets and identities into a view that supports an analyst's investigation.

      Used in 1 solution

    • Domain AI agent or copilot

      Relates detections to the MITRE ATT&CK knowledge base as reference context.

      Used in 1 solution

    • Domain AI agent or copilot

      Generates disruption scenarios for business-continuity planning and exercises.

      Used in 1 solution

    • Domain AI agent or copilot

      Flags when an important service approaches or exceeds its defined impact tolerance.

      Used in 1 solution

    • Domain AI agent or copilot

      Suggests a next step for an opportunity or customer, for the account owner to decide.

      Used in 1 solution

    • Domain AI agent or copilot

      Drafts replies to customer messages for a person to review before sending.

      Used in 1 solution

    • Domain AI agent or copilot

      Helps marketers define audience segments from connected customer data.

      Used in 1 solution

    • Domain AI agent or copilot

      Highlights customers showing signs of churn risk, for customer-success teams.

      Used in 1 solution

    • Domain AI agent or copilot

      Groups customer feedback into themes and sentiment for review.

      Used in 1 solution

    • Domain AI agent or copilot

      Helps finance teams track close tasks and reconciliations; postings stay in the finance system.

      Used in 1 solution

    • Domain AI agent or copilot

      Flags unusual journal entries for finance review before close.

      Used in 1 solution

    • Domain AI agent or copilot

      Prepares cash-flow forecasts from connected financial data for treasury review.

      Used in 1 solution

    • Domain AI agent or copilot

      Extracts key clauses from supplier contracts for procurement and legal review.

      Used in 1 solution

    • Domain AI agent or copilot

      Classifies spend lines into categories to support procurement analysis.

      Used in 1 solution

    • Domain AI agent or copilot

      Combines connected supplier data into risk indicators for procurement review.

      Used in 1 solution

    • Domain AI agent or copilot

      Prepares demand forecasts from connected sales and operations data for planners.

      Used in 1 solution

    • Domain AI agent or copilot

      Suggests stock levels and replenishment options for planners to approve.

      Used in 1 solution

    • Domain AI agent or copilot

      Suggests delivery routes for dispatch teams to confirm.

      Used in 1 solution

    • Domain AI agent or copilot

      Flags unusual changes in overall equipment effectiveness for operations teams.

      Used in 1 solution

    • Domain AI agent or copilot

      Highlights recurring quality patterns in production data for quality teams.

      Used in 1 solution

    Cross-platform

    Used in these business solutions

    Link modules are composed into these outcome-led iShield solutions — each one combines capabilities across Nexus, Connect, One, Link and GRC.

    Built for every industry

    Trusted Across Regulated Sectors

    iShield Link connects the systems regulated organisations rely on, with governed and traceable data flows.

    Financial Services

    Governed integration between core banking, payments and reporting systems.

    Healthcare

    Connections between clinical, billing and administrative systems with traceable flows.

    Technology & SaaS

    API and event integration for fast-scaling SaaS product stacks.

    Energy & Utilities

    IT/OT data integration across SCADA, asset and business systems.

    Manufacturing

    MES, ERP and supplier integration across the production chain.

    Retail & E-commerce

    Commerce, POS, inventory and marketplace integration across channels.

    Government

    Inter-agency integration with data-sovereign deployment options.

    Education

    Student information, learning and finance system integration.

    Telecommunications

    BSS/OSS and partner integration across networks and regions.

    Connect what matters. Maintain control.

    Explore Link's integration architecture, capabilities and technical patterns to understand how it can support your enterprise integration strategy.

    Your privacy choices

    We use strictly necessary storage to run this website. With your permission we also use first-party analytics to understand which pages are useful. Analytics stays off unless you choose "Accept all" or turn it on in "Manage". You can change your choice at any time from "Cookie settings" in the footer. See our Privacy Policy.