GLYDE Unity + AviontéBOLD

Overview

GLYDE Unity provides a comprehensive, bi-directional integration with AviontéBOLD, the staffing industry's enterprise applicant tracking and workforce management platform. This integration enables recruiters, hiring managers, and AI agents to access Avionté talent records, job postings, applications, and activities through a unified API layer.

The integration spans the full GLYDE ecosystem: Microsoft Teams, Copilot for Microsoft 365, Power Automate, the GLYDE Chrome Extension, the GLYDE Unity SDK, and the Model Context Protocol (MCP) for AI agent consumption. All operations are tenant-isolated using client_uuid and authenticated via OAuth2 client credentials with automatic token management.

Avionté data flows through GLYDE Unity's index-centric normalization pipeline, ensuring consistent data representation across all consumers regardless of Avionté's native field naming conventions (e.g., "Talent" instead of "Candidate", "Assignment" instead of "Placement"). Because Avionté exposes no search API for talent, jobs, companies, or contacts, GLYDE maintains its own Azure AI Search indexes and keeps them current through a smart background indexing pipeline — fed by Avionté webhooks, the GLYDE Dock for Avionté browser companion, and write-back from live reads. See Smart Background Indexing below for how that works and API Usage Metering / Data Privacy & PII for the platform services wrapped around it.

Product Demos

Short walkthroughs of the GLYDE experience across the surfaces this integration powers.

Architecture & Data Flow

GLYDE Unity acts as an orchestration layer between consuming platforms (Teams, Copilot, Power Platform, SDK) and the AviontéBOLD REST API. Requests are authenticated, normalized, and routed through the integration adaptor which handles entity-specific business logic, data mapping, and error classification.

Teams / Copilot / Power Platform / Chrome Ext / SDK / MCP Client
                    |
                    v
    ┌─────────────────────────────────────┐
    │     GLYDE Unity REST API            │
    │   api.glydeunity.com/api/unity/*    │
    │                                     │
    │  ┌─ Auth Middleware ─────────────┐   │
    │  │  API Key / JWT / Trusted App │   │
    │  │  Role-based access control   │   │
    │  └──────────────────────────────┘   │
    │                                     │
    │  ┌─ Workflow Route Handler ──────┐  │
    │  │  Validation + Orchestration   │  │
    │  └──────────────────────────────┘   │
    │              |                       │
    │              v                       │
    │  ┌─ Avionté Integration Adaptor ─┐  │
    │  │  candidates.ts / jobs / etc.  │  │
    │  │  Template Method Pattern      │  │
    │  │  Data Mapping (Index-centric) │  │
    │  └──────────────────────────────┘   │
    │              |                       │
    │              v                       │
    │  ┌─ Avionté External Connector ──┐  │
    │  │  avionte-connector.ts         │  │
    │  │  ConnectorAuthManager (OAuth2)│  │
    │  │  OpenAPI-driven operations    │  │
    │  └──────────────────────────────┘   │
    │              ^                       │
    │              │ webhooks (inbound)    │
    │  ┌─ Event Normalizer ────────────┐  │
    │  │  AvionteEventNormalizer       │  │
    │  │  FrontOfficeTenantId →     │  │
    │  │  tenant resolution            │  │
    │  └──────────────────────────────┘   │
    └──────────────|──────────────────────┘
                   |
                   v
    ┌──────────────────────────────────────┐
    │      AviontéBOLD REST API            │
    │   {tenant}.avionte.com/api/v1/*      │
    │                                      │
    │   Talent | Job | Application |       │
    │   Company | Assignment | Activity    │
    └──────────────────────────────────────┘

Authentication

Credential Fields

Session Management

Sessions are cached in Redis with the key pattern session:client:{client_uuid}:integration:avionte (encrypted Unity session blob). The session includes the OAuth2 access token, expiration timestamp, tenant identifier, and resolved service URL. TTL follows the platform profile (default connector cache window). Sessions are re-validated on each request via ConnectorAuthManager.

Token Refresh

The AvionteConnectorAuthManager checks token expiration before each API call. If the token is expired or within the refresh threshold, a new token is obtained via the client credentials flow. The OAuth2 scope is avionte.aero.compasintegrationservice. JWT tokens are validated for expiration using the exp claim.

Capabilities

Platform Access

GLYDE Unity provides unified access to AviontéBOLD across multiple Microsoft 365 and developer platforms.

Smart Background Indexing & Enrichment

Avionté exposes no search or filter API for talent, jobs, companies, or contacts — so GLYDE Unity maintains its own Azure AI Search indexes and keeps them current automatically. This section explains the five indexes, what feeds them, what enrichment is layered on, and which settings control it. All search capabilities in the table above run against these indexes, not against Avionté directly.

The five GLYDE indexes

What feeds the index

Candidate enrichment — what the cache adds on top of the ATS record

Jobs index: write-through + application enrichment

Company & contact directory indexing

Conversations list freshness

Indexing settings your tenant controls

Entity Mappings

AviontéBOLD uses different entity names and field conventions. GLYDE Unity normalizes these through the index-centric data pipeline.

Candidate → Talent

Job → Job

Application → Application

Placement → Assignment

Company (directory) → Company

Contact (directory) → Contact

Endpoint Reference

Events & Webhooks

Avionté inbound webhook processing is live and connector-owned. Inbound webhooks are received at POST /api/unity/events/webhook/avionte, the tenant is resolved from FrontOfficeTenantId via ExternalMappings, and events are normalized to the canonical GLYDE format by AvionteEventNormalizer before entering the event queue. Beyond delivery to subscribers, each event family triggers automatic indexing actions inside GLYDE (the Automatic Actions column below) — this is what keeps the search indexes current as Avionté records change. Outbound forwarding to Power Automate, Make.com, webhooks, and in-app notifications is configured per tenant through event subscriptions (see Forwarding & Filtering below).

Forwarding & Filtering

Normalized events are re-published to the destinations configured on the tenant (Clients.unity_configuration.event_system.outbound[]). Four destination types exist: webhook (generic HTTP callback with a camelCase envelope), power_automate and make (flow trigger callbacks using the canonical snake_case event object, with automatic disabling of dead triggers), and app_notification (in-app notifications). Filtering is per destination by event type: exact names (application.submitted), prefix wildcards (application.*, job.*), the catch-all *, or an empty list meaning all events — there are no per-record or per-entity filters. Flow destinations register themselves at POST /api/unity/events/power-automate/subscriptions/register (Make.com and generic webhook variants exist alongside; GET .../trigger-options lists the available filters). Connector defaults (inbound subscription set, processing flags, notification destinations) are provisioned at onboarding and can be re-synced via POST /api/unity/events/defaults/sync. Delivery retries with exponential backoff (3 attempts); failed deliveries are retained 7 days for inspection, delivery attempts 90 days, and a daily maintenance sweep probes and auto-disables persistently failing destinations (also available on demand via POST /api/unity/events/maintenance/run, dry-run first).

API Usage Metering

Every call GLYDE Unity makes to Avionté on your tenant's behalf is counted — both the ATS proxy operations you invoke directly and the workflow/adaptor calls made for you. Counts roll up per hour into a durable table and are exposed to tenant admins, so you can see exactly what the integration is doing against your Avionté API subscription.

What is counted

How it is stored

Where to see it

Caveats

Data Privacy & PII Masking

Tenants can control what personally identifiable information GLYDE's AI agents may see, configured per client under Clients.unity_configuration.pii_policy. Scope matters: masking is model-facing only — it changes what LLM-based agents process, never what the direct Unity API returns, what Power Automate/Make flows receive, or what is stored in the ATS, GLYDE's database, or the search indexes.

Settings

How it behaves end-to-end

Configuring it

Onboarding & Activation

New tenants are provisioned and activated through the GLYDE onboarding wizard in the web app, backed by Unity trusted setup/activation endpoints. The wizard walks through connecting the ATS, granting permissions, mapping fields with live Avionté dropdowns, provisioning event subscriptions, and go-live — with a support-ticket approval loop before the tenant starts indexing.

Wizard steps (GLYDE web app)

Activation phases & the gate

Power Automate setup & dropdown mappings

Configuration Requirements

• OAuth2 Client CredentialsREQUIRED

  Avionté issues client_id and client_secret for API access. These must be stored in Azure Key Vault via the GLYDE Unity client configuration.

  client_id: "glyde-integration-client"

• Tenant IdentifierREQUIRED

  The Avionté tenant identifier is required for all API calls and is injected as the Tenant HTTP header. This is typically the company's Avionté instance identifier.

  tenant: "acme-staffing"

• Activity Type ConfigurationREQUIRED

  Client-specific activity type IDs for logging notes in Avionté. Configured in integration_data.AvionteConfiguration. Resolution order: general_activity_type, then Talent.general_activity_type (human_review uses Talent.human_review_activity_type).

  AvionteConfiguration.general_activity_type: 42

• Activity Author User IDREQUIRED

  Avionté user ID used as the author for GLYDE-created activities. Resolution order: new_submission_user, then glyde_user_id, then recruiter ExternalMappings (source=avionte, type=recruiter) for the requesting GLYDE user.

  AvionteConfiguration.new_submission_user: 1001

• Human Review Activity TypeREQUIRED

  Activity type ID for "Glyde Contact Requested" notes (human_review flag). Configured per-client in AvionteConfiguration.Talent.human_review_activity_type.

  AvionteConfiguration.Talent.human_review_activity_type: 15

• Webhook Subscription (Optional)

  To receive live Avionté events, register the GLYDE webhook URL ({unityBaseUrl}/api/unity/events/webhook/avionte) in the Avionté webhook configuration and ensure an ExternalMapping exists for the FrontOfficeTenantId. Default subscriptions can be provisioned via POST /api/unity/events/defaults/sync.

  Webhook URL: https://api.glydeunity.com/api/unity/events/webhook/avionte

• Chrome Extension ID (Optional)

  When using the GLYDE Chrome Extension for ATS cache sync, set UNITY_AVIONTE_EXTENSION_CHROME_ID so the extension origin is allowed to complete OTP registration and enqueue candidate IDs.

  UNITY_AVIONTE_EXTENSION_CHROME_ID: "abcdefghijklmnopqrstuvwxyz"

• Smart Indexing Settings (Optional)

  Tenant-level switches that govern background indexing and enrichment: event_system.processing.update_ats_cache (default true — webhook-driven cache refresh; false produces a "live but empty" tenant), search.enrich_jobs_index_applications (default false — jobs-index applicant buckets; also requires the platform-side kill switch), ats_status_screen_result_mapping (ATS status → screen result), ats_cache_chat_summary_notes (ATS notes into chat summaries), and find_defaults.staleness_ms (index staleness threshold before live fallback). See Smart Background Indexing.

  search: { enrich_jobs_index_applications: true }

• PII Policy (Optional)

  Per-tenant AI data-privacy posture under pii_policy: enabled (default false), entity_types (email/phone/ssn/credit_card), token_format (bracketed/hash), mask_mode (reversible token vs one-way last4 per entity), restore_on_output, and masked_candidate_fields (DOB/age masking, default on). Model-facing only — direct API responses and stored data are never tokenized. See Data Privacy & PII Masking.

  pii_policy: { enabled: true, mask_mode: { ssn: "last4" } }

• Integration TypeREQUIRED

  The client's integration_type must be set to "avionte" in the GLYDE client configuration for the adaptor router to select the correct integration.

  integration_type: "avionte"

• API Base URL (Optional)

  Override the default AviontéBOLD API base URL if using a non-standard endpoint.

  service_url: "https://api.avionte.com"

Known Limitations

• No live search API for Talent or Jobs. Avionté exposes no search/filter endpoint — GLYDE serves candidate/job search from the Azure AI Search index and uses QueryMultipleTalents/QueryMultipleJobs batch reads for live pulls. The connector's canonical searchCandidates/searchJobs methods return NOT_IMPLEMENTED and atsProfile.searchCapabilities.supported is false.
• Candidate entity is called "Talent" in Avionté — all API operations use this naming convention.
• Placement entity is called "Assignment" in Avionté.
• Record updates use full PUT (not PATCH) — all fields must be provided on updates, not just changed fields.
• Application updates return NOT_IMPLEMENTED — Avionté does not support direct application modifications through the current API version.
• Live job get-by-id is not implemented — job reads resolve from the GLYDE search index; only create and update write through to Avionté.
• Job notes are not supported — unified activities write talent activities only (CreateTalentActivity). Activity retrieval from Avionté is not implemented.
• SMS messages and emails are mirrored to Avionté as talent activity notes (CreateTalentActivity, subtype communication/email_sent) via the tenant-gated communication write-back queue (unity_configuration.communication_writeback.enabled, default on) — but only sends carrying candidate/application context; raw-recipient sends with no candidate link are not mirrored.
• Job create requires Avionte front_office__JobDto fields — map UI payload via JobDataMapper, inject branchId / ownerUserId server-side, and supply tenant Avionte ids from AvionteConfiguration (company_id, job_status_id, job_contact_id, job_order_type_id, front_office_id, worksite_address_id) on integration_data and/or unity_configuration.
• The Avionté OpenAPI spec uses camelCase field naming, which differs from GLYDE Unity's snake_case convention. Mapping is handled automatically.
• Entity metadata inspection may return 501 from the connector for some entity types — Buddy falls back to the atsProfile.entities catalog with a structured "unsupported" envelope.
• Pagination uses offset/limit pattern with a default limit of 25 records per page.
• The Tenant header is required for all API calls and is automatically injected by the connector.
• Avionté deep links require the tenant atsBaseUrl (myavionte.com subdomain) to be configured; otherwise links fall back to the GLYDE Screen /dl/ resolver.
• There is no dedicated Avionté recommended-fields provider for LLM tool calls — prompts rely on unityInspectATSOperation / unityInspectATSEntityFields output.
• Jobs-index application enrichment is dual-gated: the tenant flag search.enrich_jobs_index_applications takes effect only when the platform env kill switch GLYDE_JOBS_INDEX_APPLICATION_ENRICHMENT=1 is also enabled — the feature ships dark by default.
• Connector usage metering is best-effort — near-real-time (≈25-minute lag), small windows can be lost on Redis failover, and it is not invoicing-grade. Usage-based throttling/quotas are not enforced.
• The smart background cache ships only in the GLYDE Dock for Avionté — the classic GLYDE Dock (workspace) and the Buddy Chrome Extension (AI assistant) never read or cache ATS data, and the enqueue route is Avionté-gated.
• PII masking is model-facing only — it never tokenizes direct Unity API responses, Power Automate/Make deliveries, or data at rest in the ATS, GLYDE database, and search indexes.

Version History