Scattered partner docs across Confluence, Drive & GitHub — portal unifies access

Overview

An industrial Internet of Things (IoT) platform vendor struggled with scattered, outdated partner enablement content spread across drives, wikis, and code repos. Channel teams, solutions partners, and OEMs pulled different versions of playbooks and Software Development Kit (SDK) guides, creating inconsistent messaging and preventable support tickets. Intelligex implemented a partner knowledge portal that indexed existing sources with permissions-aware search, freshness checks, and auto-rendered API documentation. Without replacing tools, the portal surfaced the latest playbooks and integration guides, introduced review gates, and gave partners a single, trustworthy entry point. Onboarding moved more smoothly, support handled fewer repetitious requests, and field teams spoke from the same page.

Client Profile

• Industry: Industrial IoT platform (edge devices, gateways, and cloud services)
• Company size (range): Mid-market with a global partner ecosystem
• Stage: Growth-stage vendor scaling partner-led deployments
• Department owner: Sales & Business Development (Partner/Alliances)
• Other stakeholders: Product Marketing, Developer Relations, Support, Solutions Engineering, Legal, IT/Security

The Challenge

Partners needed dependable guidance for messaging, solution design, and implementation details. In reality, content lived in many places: Confluence pages for positioning, Google Drive for pitch decks, GitHub for SDKs, and PDFs emailed during onboarding. Search was inconsistent and did not respect permissions. Partners routinely found outdated firmware notes, stale integration diagrams, or expired launch checklists. Channel managers spent time forwarding attachments and clarifying what was current.

Support queues reflected the fragmentation. Tickets asked basic “where is the latest” questions, and repetitive setup issues stemmed from old instructions. API references existed, but they were split across repos and wiki pages without a single canonical view. The company needed to keep existing systems—no appetite to replatform documentation, identity, or storage—while creating a portal that used what already worked, ensured the newest content was easy to find, and locked sensitive material behind the right roles and Non-Disclosure Agreement (NDA) tiers.

Why It Was Happening

There was no shared taxonomy or content ownership spanning tools. Playbooks, SDK guides, and launch kits were produced by different teams with different naming patterns and review cadences. Some pages were refreshed frequently; others had not been touched since earlier releases. Without a “freshness” signal, partners treated whatever they found as authoritative.

Permissions were inconsistent across sources. A partner who had access in one system could hit a dead end in another, and generic search ignored role boundaries. API documentation relied on manually updated wiki pages, so different endpoints and parameter names existed across versions. Changelogs were scattered, and deprecations were communicated late or informally.

The Solution

We implemented a partner knowledge portal that federated existing content into one searchable, role-aware experience. The portal indexed Confluence, Google Drive, and GitHub, applied a unified taxonomy, and labeled every item with freshness and approval status. API references were generated from machine-readable specifications so there was a single source of truth for endpoints and examples. Single Sign-On (SSO) ensured partners saw only what their agreements allowed, and content owners approved updates through review gates before publication. Nothing was ripped out; the portal orchestrated tools partners and internal teams already used.

• SSO integration with the existing identity provider to enforce role- and tier-based access across sources (Okta SSO)
• Connectors to Confluence, Google Drive, and GitHub that ingest metadata, permissions, and version history
• Permissions-aware search that respects source ACLs and partner tiers, with filters for product, version, and use case
• Freshness scoring based on last update, approval timestamp, and linked release tags; stale flags and owner notifications
• API documentation generated from OpenAPI definitions with automatic rendering and try-it examples (OpenAPI Specification, Swagger UI)
• Governed content lifecycle with ownership, draft/publish states, and required Legal/Product Marketing approvals
• Release notes and changelog aggregation from GitHub tags and Confluence pages with partner-facing summaries
• Template library for co-marketing and solution briefs with approval badges and expiration
• Request intake and feedback forms that route to content owners and Support for clarifications and updates
• Analytics dashboards showing search terms, zero-result queries, stale content, and partner engagement
• Branch protections and review rules on GitHub repos that house SDK and API specs to prevent unapproved changes (GitHub Protected Branches)

Implementation

• Discovery: Cataloged current content sources, permission models, and partner tiers. Interviewed channel managers, Developer Relations, and Support to identify high-friction topics and repetitive tickets. Mapped content owners and existing review patterns.
• Design: Defined a shared taxonomy for products, versions, personas, and use cases. Documented role definitions tied to partner agreements and NDA tiers. Established freshness criteria, approval gates, and deprecation workflows. Designed search facets and portal navigation to minimize clicks from landing to the right artifact.
• Build: Implemented SSO and role mapping. Built connectors to ingest content, metadata, and ACLs from Confluence, Drive, and GitHub. Stood up an index with permission filters and freshness scoring. Integrated OpenAPI sources and Swagger UI for live API docs. Added governance states and owner workflows for draft, review, and publish.
• Testing and QA: Piloted with a subset of partners across tiers. Verified that permission boundaries held and that search returned only authorized, fresh content. Checked API docs against current SDKs. Ran deprecation tests to confirm stale items were flagged and redirected correctly.
• Rollout: Launched with read-only aggregation first, then enabled publish/approval workflows after owners validated mappings. Communicated a sunset plan for legacy wiki indexes and set redirects. Kept original repositories intact and editable; the portal reflected source-of-truth updates automatically.
• Training and hand-off: Delivered short guides for channel managers and content owners on tagging, approvals, and freshness. Provided partner-facing “start here” pages by persona. Established a human-in-the-loop review board for sensitive claims and NDA-gated materials.

Results

Partners found current playbooks, integration diagrams, and SDK guides in one place, filtered to their entitlements. Repetitive tickets for basic setup and version confusion decreased because the portal highlighted the approved, most recent artifacts and routed questions to owners when needed. API references matched the running services, and deprecations were communicated with clear timelines and migration notes.

Channel managers and solutions engineers aligned on consistent narratives. Instead of forwarding attachments, they shared durable links that remained accurate as owners updated content. Support and Developer Relations focused on higher-value issues, leveraging analytics from portal search to prioritize documentation updates. Internal teams gained visibility into content health and could address stale items before partners discovered them.

What Changed for the Team

• Before: Content lived across drives, wikis, and repos with unclear versions. After: A single portal indexed sources with freshness and approval badges.
• Before: Partners asked where the latest SDK or API docs lived. After: OpenAPI-driven references and “latest” indicators removed guesswork.
• Before: Search exposed sensitive or irrelevant results. After: Permissions-aware search respected roles, tiers, and NDAs.
• Before: Changelogs were scattered and late. After: Release notes aggregated and surfaced partner-facing summaries with clear deprecations.
• Before: Content owners learned about gaps from tickets. After: Analytics highlighted top queries, zero results, and stale content proactively.

Key Takeaways

• Federate; do not migrate. Index existing sources and layer governance rather than replacing tools teams already use.
• Make search permission-aware and freshness-aware so partners see the right, current content for their tier.
• Generate API docs from specifications to maintain a single source of truth as services evolve.
• Establish clear ownership and approval gates across Product Marketing, Legal, and Developer Relations.
• Use portal analytics to drive documentation priorities and reduce repetitive support work.

FAQ

What tools did this integrate with?
The portal integrated with Confluence for playbooks and solution content, Google Drive for decks and templates, and GitHub for SDKs and API specifications. Single Sign-On used the client’s identity provider to map partner roles and tiers, and OpenAPI definitions rendered live API docs via Swagger UI. We did not replace any repositories; the portal reflected the current state of each source.

How did you handle quality control and governance?
Each item carried an owner, approval status, and freshness signal. Drafts required Product Marketing and, when relevant, Legal approval before publishing. Branch protections in GitHub prevented unreviewed changes to specs. Deprecation workflows set sunset dates and redirects. Sensitive materials were NDA-gated, and audit logs tracked who published what and when.

How did you roll this out without disruption?
We launched with read-only aggregation, leaving authors to continue editing in Confluence, Drive, and GitHub. After content owners validated tags, permissions, and mappings, we enabled approval workflows. Legacy index pages were redirected to the portal, and partners received a concise “start here” guide. No core systems were removed.

How did permissions-aware search work with NDA tiers?
Roles and tiers from Single Sign-On determined which content appeared in results. The index stored only metadata needed to enforce visibility, and queries were filtered by the user’s entitlements. NDA-gated documents were visible only to authorized partners and internal staff with the appropriate role.

How were API changes communicated?
OpenAPI specs served as the canonical source. When a spec changed, the portal updated the rendered docs automatically and generated a partner-facing changelog entry. Deprecations included migration notes and dates, and owners could pin upgrade guides so they appeared alongside affected endpoints.