Partner Studio Guide
How to bring your product, data, and domain expertise into ABB Ability™ BuildingPro Suites
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:
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
How it works
Structure first: the building structure (sites, floors, rooms, assets) is created in BuildingPro Suites — this is the canonical model.
Connect: your system publishes to an MQTT topic structure or exposes an OPC UA address space.
Map: incoming data points are mapped onto BPS assets and attributes (mapping hints from your payload structure speed this up).
Use: data is immediately available for dashboards, alarming, rules, and Suite analytics.
What you provide / what we provide
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
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
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
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 · 💻 GitHub: 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
Design considerations
Single sign-on: token or session hand-off so users don't log in twice
Context passing: URL parameters or
postMessagefor asset/room/user contextVisual 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
The co-development process
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
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?
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
Describe your use case — a short outline of the module or integration idea and the customer problem it solves
Describe your domain know-how — what you bring that nobody else does
Joint scoping workshop — we map your idea to the right option (A–D) together
Decide the setup — technical path, roles, and commercial frame
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!
App SDK: App SDK documentation
GitHub (SDK, app template, mock, client libraries): github.com/eliona-smart-building-assistant
API reference: api.eliona.io
Last updated