> For the complete documentation index, see [llms.txt](https://docs.buildings.ability.abb/collection/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.buildings.ability.abb/collection/for-developers/partner-studio-guide.md).

# Partner Studio Guide

This guide is for startups, technology vendors, and solution partners who want to integrate with — or build on — BuildingPro Suites (BPS). It describes four integration paths, from a lightweight data connection to a fully co-developed native module, and helps you choose the right one for your product and business model.

***

### 1. Why partner with BuildingPro Suites?

BuildingPro Suites is a cloud-first smart building platform with a layered architecture:

* **Mandatory Base** — connectivity, asset modeling, identity, and governance
* **Platform toolbox** — dashboards, rules, analytics, APIs, and app framework
* **Suites** — vertical modules such as Energy & Sustainability Intelligence, Occupant Experience, and Space & Assets Analytics

As a partner, you plug into an existing enterprise platform with 100+ OT protocol integrations, a marketplace, a global ABB sales organization, and a hardware ecosystem — instead of building all of that yourself.

**The core architectural principle:** *structure is owned by the Suites; data points are mapped onto it.* BuildingPro Suites holds the canonical asset and location model (buildings, floors, rooms, equipment). Whatever integration path you choose, your data and functionality attach to that model.

***

### 2. The four integration paths at a glance

There are four ways to integrate, ordered by increasing depth of integration and partnership:

```mermaid
flowchart LR
    A["**Option A**<br/>Data-only<br/>MQTT / OPC UA"] --> B["**Option B**<br/>Suites App<br/>Auto-model + KPIs"]
    B --> C["**Option C**<br/>Embedded<br/>Partner UI"]
    C --> D["**Option D**<br/>Full Module<br/>Co-Development"]

    style A fill:#e8f4fd,stroke:#0f62fe
    style B fill:#d0e8fb,stroke:#0f62fe
    style C fill:#b8dcf9,stroke:#0f62fe
    style D fill:#ff000f,stroke:#a30005,color:#fff
```

The options are **not mutually exclusive** — many partnerships start with Option A or C to prove value quickly, then evolve toward B or D.

|                         | **A — Data-only**                      | **B — Suites App**                              | **C — Embedded UI**                    | **D — Full Module**                           |
| ----------------------- | -------------------------------------- | ----------------------------------------------- | -------------------------------------- | --------------------------------------------- |
| **What it is**          | Your system streams data into BPS      | You build a connector app on the App SDK        | Your existing UI runs inside BPS       | Jointly built native BPS module               |
| **Who builds**          | Partner (data export)                  | Partner (with BPS SDK)                          | Partner + BPS (embedding)              | BPS dev team + partner domain expertise       |
| **Effort for partner**  | Days–weeks                             | Weeks–months                                    | Days–weeks                             | Months (ongoing)                              |
| **User experience**     | BPS-native (generic)                   | BPS-native (templated)                          | Partner look & feel                    | Unified BPS UX                                |
| **Analytics & AI**      | Basic (raw data)                       | Standard KPIs & rules                           | Limited (stays in partner UI)          | Full BPS analytics & AI                       |
| **Marketplace listing** | No                                     | Yes                                             | Optional                               | Yes — sold as BPS module                      |
| **Commercial model**    | Project-based                          | App licensing                                   | Project / OEM                          | Revenue sharing                               |
| **Best for**            | Fast proof of value, existing BMS/GRMS | Repeatable, scalable device/system integrations | Mature partner products with strong UI | Deep domain plays (ESG, hospitality, grid, …) |

***

### 3. Option A — Data-only integration (MQTT / OPC UA / Events)

#### Concept

The simplest path: your system — for example a GRMS, BMS, or IoT platform — publishes data via standard interfaces such as **MQTT** or **OPC UA**. BuildingPro Suites consumes, normalizes, and stores the data against its asset model. From there, all standard platform capabilities apply: dashboards, alarms, rules, trend analysis, and reporting.

No partner-side development against BPS APIs is required — only a configured data export from your system.

#### Architecture

```mermaid
flowchart LR
    subgraph Partner["Partner System"]
        PS["GRMS / BMS /<br/>IoT Platform"]
    end

    subgraph Transport["Standard Interfaces"]
        MQTT["MQTT Broker"]
        OPC["OPC UA Server"]
    end

    subgraph BPS["BuildingPro Suites"]
        ING["Connectivity Layer<br/>(ingestion & normalization)"]
        AM["Asset Model<br/>(canonical structure)"]
        TS["Time-Series Store"]
        VIS["Dashboards, Alarms,<br/>Rules, Reports"]
    end

    PS -->|publish| MQTT --> ING
    PS -->|expose| OPC --> ING
    ING -->|map data points| AM
    ING --> TS
    AM --> VIS
    TS --> VIS

    style BPS fill:#f5f5f5,stroke:#ff000f
```

#### How it works

1. **Structure first:** the building structure (sites, floors, rooms, assets) is created in BuildingPro Suites — this is the canonical model.
2. **Connect:** your system publishes to an MQTT topic structure or exposes an OPC UA address space.
3. **Map:** incoming data points are mapped onto BPS assets and attributes (mapping hints from your payload structure speed this up).
4. **Use:** data is immediately available for dashboards, alarming, rules, and Suite analytics.

#### What you provide / what we provide

| Partner provides                                 | BuildingPro provides                  |
| ------------------------------------------------ | ------------------------------------- |
| Data export via MQTT or OPC UA                   | Ingestion, normalization, persistence |
| Payload documentation (topics, units, semantics) | Asset modeling and mapping tooling    |
| Test environment or sample data                  | Dashboards, alarms, rules, reporting  |

#### When to choose Option A

* You want to prove value in a pilot **within days, not months**
* Your system already speaks MQTT or OPC UA
* The customer's primary need is *data visibility* — monitoring, alarming, reporting

📖 Documentation: [Connecting devices to BuildingPro Suites](/collection/mandatory-base/platform-core/connect-hub/connectivity-as-a-service.md)

***

### 4. Option B — Suites App: data + auto-model + auto-KPIs

#### Concept

You develop a **Suites App** (connector) using the **BuildingPro Suites App SDK**. Unlike Option A, your app doesn't just deliver data — it actively drives the platform:

* Connects to your system via its **REST API or SDK**
* **Automatically creates assets and attributes** from templates (Continuous Asset Creation)
* **Automatically provisions KPIs, targets, and rules**
* **Deploys default dashboards** so customers get a working solution out of the box

The result is a repeatable, productized integration: install the app, enter credentials, and the full solution self-configures. This is the standard path to a **Marketplace listing**.

#### Architecture

```mermaid
flowchart LR
    subgraph Partner["Partner Cloud / System"]
        API["Partner REST API / SDK"]
    end

    subgraph App["Partner Suites App (Docker)"]
        CONN["Connector Logic (Go)"]
        CAC["Continuous Asset Creation<br/>(assets, attributes, mapping)"]
        PROV["Provisioning<br/>(KPIs, targets, rules,<br/>dashboard templates)"]
        DB[("App Schema<br/>PostgreSQL")]
        OAPI["App API<br/>(openapi.yaml)"]
    end

    subgraph BPS["BuildingPro Suites"]
        CORE["BPS Core"]
        RAPI["BPS REST API +<br/>WebSockets"]
        AM["Asset Model"]
        DASH["Dashboards & KPIs"]
        MP["Marketplace"]
    end

    API <-->|poll / subscribe| CONN
    CONN --> CAC & PROV
    CAC & PROV -->|API_TOKEN| RAPI --> CORE
    CORE --> AM --> DASH
    CONN <--> DB
    OAPI -.->|configuration UI| CORE
    App -.->|listed & installed via| MP

    style BPS fill:#f5f5f5,stroke:#ff000f
    style App fill:#e8f4fd,stroke:#0f62fe
```

#### Technical framework (App SDK)

Apps run as **Docker containers** inside a BuildingPro Suites environment and follow a defined contract:

* **Language:** Go (pre-fabricated client libraries available)
* **Platform access:** exclusively via the BPS REST API and WebSockets (`API_ENDPOINT`, `API_TOKEN`)
* **Persistence:** app-specific schema in PostgreSQL (`CONNECTION_STRING`)
* **App API:** own functions exposed via a custom API described in `openapi.yaml` (`API_SERVER_PORT`)
* **Lifecycle:** activation → installation → initialization → updates/migration → uninstallation
* **Best practice:** Continuous Asset Creation (CAC) — the app detects new devices in your system and creates/updates/removes the corresponding BPS assets automatically, including dashboard templates

A mock environment lets you develop and test without a full BPS installation, and an app template repository gets you started in hours.

#### What you provide / what we provide

| Partner provides                                      | BuildingPro provides                                      |
| ----------------------------------------------------- | --------------------------------------------------------- |
| App development (Go, against the SDK)                 | App SDK, client libraries, app template, mock environment |
| Asset templates, KPI definitions, dashboard templates | Review, certification, Marketplace listing                |
| Maintenance and versioning of the app                 | Deployment framework, platform operations                 |

#### When to choose Option B

* You want a **repeatable product**, not a per-project integration
* Your system has a good API and you have (or can source) Go development capacity
* You want Marketplace visibility and installation-in-minutes for customers

📖 Documentation: [App SDK](/collection/for-developers/app-sdk.md) · 💻 GitHub: [github.com/eliona-smart-building-assistant](https://github.com/eliona-smart-building-assistant)

***

### 5. Option C — Embedded Partner UI

#### Concept

If you already have a mature, differentiated user interface, we can embed it directly into BuildingPro Suites — the customer works in one platform, and your product appears as a native part of it. Three embedding patterns are available:

* **iFrame** — fastest path; your web app is framed inside a BPS page
* **Web Component** — deeper integration; your UI components render inside BPS views
* **Reverse proxy** — BPS serves your UI under its own domain for a seamless experience

Optionally, BPS passes **context** into your UI — e.g. the currently selected hotel, room, or asset — so your interface opens in the right place ("deep linking with context").

#### Architecture

```mermaid
flowchart LR
    subgraph User["User"]
        BR["Browser<br/>(single BPS session)"]
    end

    subgraph BPS["BuildingPro Suites"]
        SHELL["BPS UI Shell<br/>(navigation, identity)"]
        CTX["Context Provider<br/>(site / room / asset,<br/>user, language)"]
        RP["Reverse Proxy<br/>(optional)"]
    end

    subgraph Partner["Partner Product"]
        PUI["Partner Web UI"]
        PBE["Partner Backend"]
    end

    BR --> SHELL
    SHELL -->|iFrame / Web Component| PUI
    SHELL --> RP --> PUI
    CTX -->|context parameters /<br/>postMessage| PUI
    PUI <--> PBE

    style BPS fill:#f5f5f5,stroke:#ff000f
    style Partner fill:#e8f4fd,stroke:#0f62fe
```

#### Design considerations

* **Single sign-on:** token or session hand-off so users don't log in twice
* **Context passing:** URL parameters or `postMessage` for asset/room/user context
* **Visual fit:** optional "lightweight visu" styling to align colors and typography with BPS
* **Combine with Option A:** many partners embed their UI *and* stream data into BPS, so their information also appears in cross-domain dashboards and reports

#### When to choose Option C

* Your product's UI is a core differentiator and rebuilding it makes no sense
* You need to be inside the customer's daily platform without deep re-engineering
* As a bridge: keep your UI today, migrate functionality natively over time

***

### 6. Option D — Full Module Co-Development

#### Concept

The deepest partnership: we combine **your domain expertise** (room logic, workflows, KPIs, operational processes, compliance know-how) with **our platform and development capacity** to build a **native BuildingPro Suites module** with:

* **Unified UX** — built on the BPS design system, indistinguishable from core Suites
* **Analytics & AI** — full access to platform ML/AI capabilities
* **Standard KPIs** — productized metrics, targets, and benchmarks for the domain

The module becomes a sellable unit within BuildingPro Suites — sold through ABB's global sales organization and partner network, with a **revenue share** for you.

#### Architecture

```mermaid
flowchart TB
    subgraph Inputs["Partner Contribution"]
        DOM["Domain know-how<br/>(use cases, KPIs, workflows)"]
        MKT["Market access &<br/>customer understanding"]
        VAL["Validation & QA<br/>(business correctness)"]
    end

    subgraph Module["Native BPS Module"]
        UX["Unified UX<br/>(BPS design system)"]
        LOGIC["Business logic,<br/>rules & workflows"]
        AI["Analytics & AI/ML"]
        KPI["Standard KPIs<br/>& data models"]
    end

    subgraph Platform["BuildingPro Contribution"]
        DEV["Development team<br/>(backend, frontend, QA, DevOps)"]
        PLAT["Platform: connectivity,<br/>asset model, identity"]
        GTM["Marketplace + global<br/>ABB sales & partners"]
        HW["Hardware ecosystem<br/>(edge, gateways, sensors)"]
    end

    Inputs --> Module
    Platform --> Module
    Module -->|"sold as part of BPS<br/>→ revenue sharing"| GTM

    style Module fill:#ff000f,stroke:#a30005,color:#fff
    style Inputs fill:#e8f4fd,stroke:#0f62fe
    style Platform fill:#f5f5f5,stroke:#666
```

#### The co-development process

```mermaid
flowchart LR
    P1["**1. Ideation<br/>& Scoping**<br/>use case, market,<br/>MVP definition"] --> P2["**2. Product<br/>& Design**<br/>KPIs, data models,<br/>UX concepts"]
    P2 --> P3["**3. Development<br/>& Integration**<br/>BPS dev team builds,<br/>partner validates"]
    P3 --> P4["**4. Packaging<br/>& Pricing**<br/>licensing, Marketplace,<br/>sales materials"]
    P4 --> P5["**5. Go-to-Market**<br/>joint sales strategy,<br/>enablement,<br/>feedback loop"]
```

| Phase                             | Key activities                                                                                            | Outcome                                            |
| --------------------------------- | --------------------------------------------------------------------------------------------------------- | -------------------------------------------------- |
| **1 — Ideation & Scoping**        | Joint use-case definition, market problem, target customers, MVP vs. extensions, high-level business case | Module vision, scope, rough roadmap                |
| **2 — Product & Design**          | Joint workshops: KPIs, data models, workflows, user journeys, UX mockups                                  | Product requirements, UX concepts, clear MVP scope |
| **3 — Development & Integration** | Implementation by BPS dev team, regular reviews and demos, business validation by partner                 | Working module, accepted by both sides             |
| **4 — Packaging & Pricing**       | Licensing and pricing model, Marketplace positioning, product descriptions, demo scenarios                | Sellable, listed module                            |
| **5 — Go-to-Market & Sales**      | Joint sales strategy, enablement of ABB sales and partners, partner network activation                    | Revenue and market feedback loop                   |

#### Roles

**You (partner)** can take one or several roles: Domain Owner / Subject Matter Expert, Product Owner for the module, Co-Designer (UX), Quality & Validation Partner, Go-to-Market & Sales Partner, Device/Hardware Domain Expert.

**We (ABB / BuildingPro)** own the platform and architecture and provide development (backend, frontend, DevOps, QA, AI/ML), the UX/UI design system, Marketplace packaging and deployment, global sales and distribution, and operations, support, and scaling.

#### Commercial model & IP

* **Revenue sharing:** you receive a share of every sold module. The share reflects your contribution to the product (IP, domain know-how, product definition), your contribution to sales and marketing, and your long-term role in maintenance and further development. The concrete model is agreed individually per partner and module.
* **IP & ownership:** the module is part of BuildingPro Suites; ABB operates, sells, and maintains it. You contribute domain IP and know-how. Details on IP usage, licensing, and rights are regulated contractually.

#### What we expect / what you can expect

| We expect from partners                        | Partners can expect from us                   |
| ---------------------------------------------- | --------------------------------------------- |
| Deep domain expertise                          | Access to the BPS platform and architecture   |
| Active product contribution — not just an idea | Professional product and software development |
| Availability for reviews, testing, feedback    | UX/UI, QA, DevOps, and operations             |
| Market access or strong market knowledge       | Marketplace and global sales reach            |
| Long-term interest in the module's success     | Scaling in enterprise environments            |

***

### 7. Which option is right for you?

```mermaid
flowchart TD
    START["What do you want<br/>to achieve?"] --> Q1{"Do you mainly want your<br/>data visible in BPS?"}
    Q1 -->|Yes, quickly| A["**Option A**<br/>Data-only via<br/>MQTT / OPC UA"]
    Q1 -->|No, more than data| Q2{"Do you have a mature UI<br/>that is your differentiator?"}
    Q2 -->|Yes| C["**Option C**<br/>Embedded Partner UI<br/>(often combined with A)"]
    Q2 -->|No / UI is secondary| Q3{"Do you want a repeatable,<br/>self-installing product<br/>in the Marketplace?"}
    Q3 -->|Yes| B["**Option B**<br/>Suites App with<br/>auto-model & auto-KPIs"]
    Q3 -->|"We want to build a<br/>joint business"| D["**Option D**<br/>Full Module<br/>Co-Development"]

    A -.->|grow over time| B
    C -.->|migrate natively| D
    B -.->|deepen partnership| D

    style D fill:#ff000f,stroke:#a30005,color:#fff
```

**Rules of thumb:**

* **Prove value in a pilot next month** → Option A
* **Ship a repeatable integration product** → Option B
* **Your UI is the product** → Option C (plus A for cross-domain data)
* **Build a joint business on shared revenue** → Option D

And remember: these are stages, not silos. A typical partner journey is **A → B → D** or **C → D**.

***

### 8. Getting started

1. **Describe your use case** — a short outline of the module or integration idea and the customer problem it solves
2. **Describe your domain know-how** — what you bring that nobody else does
3. **Joint scoping workshop** — we map your idea to the right option (A–D) together
4. **Decide the setup** — technical path, roles, and commercial frame
5. **Start** — pilot (A/C), app development (B), or concept & design phase (D)

**In short:** you bring the domain expertise, the use cases, and the market — we bring the platform, the scale, and the sales engine. Together, we build a product that helps both sides grow.

📩 Contact the BuildingPro Suites partner team to schedule a scoping workshop.

***

### Resources

* **Documentation:** [Welcome to the ABB Ability™ BuildingPro Suites guide!](/collection/preface/readme.md)
* **App SDK:** [App SDK documentation](/collection/for-developers/app-sdk.md)
* **GitHub (SDK, app template, mock, client libraries):** [github.com/eliona-smart-building-assistant](https://github.com/eliona-smart-building-assistant)
* **API reference:** [api.eliona.io](https://api.eliona.io/)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.buildings.ability.abb/collection/for-developers/partner-studio-guide.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.