🔌Integrations

Slack — channel notifications

Connect Slack to push alerts and work-order updates into the channels your team already lives in. Setup is a one-click OAuth flow: you authorize the Myncel app inside your Slack workspace, choose a default channel, and Myncel starts posting events the next time something happens.

• Messages include rich formatting — work-order title, machine, priority, assignee, and a deep link back to /work-orders/<id>.
• Critical alerts include a red highlight bar; warnings use amber; info uses neutral grey.
• Disconnecting from /settings/integrations revokes the Slack token immediately and stops all posting.

1. Open /settings/integrations.
2. Click Connect under Slack. You are redirected to Slack to approve the workspace install.
3. Pick the channel that should receive Myncel notifications (e.g. #maintenance or #on-call). You can change this later under /settings/notifications.
4. Choose which event types post to Slack — work order created, work order completed, alert triggered, PM overdue. Each can be toggled independently.
5. Click Save. From the Connected card you can press 💬 Send Digest to post a one-shot maintenance summary to verify the channel is wired correctly.

Microsoft Teams — adaptive-card alerts

Microsoft Teams is now a first-class native integration. Myncel posts Adaptive Card v1.4 messages to any Teams channel through a per-channel Incoming Webhook URL — no app install, no admin approval, no OAuth dance. Each Teams channel can have its own webhook, so different sites or teams can receive different subsets of events by connecting Myncel to multiple channels (one connection per Myncel organization is supported today; multi-channel is on the roadmap).

Cards are colour-coded by severity (critical / error → red, warning → amber, info → blue, success → green) and include the machine name, sensor or task, severity, and an "Open in Myncel" action button that deep-links to the relevant page.

• Events that fire a Teams card today: work_order.created, work_order.completed, alert.triggered, pm.overdue.
• Severity → colour mapping: CRITICAL/HIGH → attention (red), WARNING/MEDIUM → warning (amber), INFO/LOW → accent (blue), SUCCESS → good (green).
• Disconnecting from /settings/integrations revokes the saved webhook URL — Teams will stop receiving cards immediately.

1. In Microsoft Teams, open the channel that should receive Myncel alerts.
2. Click the channel ••• menu → Connectors. (On newer tenants this may be Workflows → "Post to a channel when a webhook request is received".)
3. Find Incoming Webhook → Configure. Give it a name (e.g. "Myncel"), optionally upload an icon, and click Create.
4. Copy the long URL that begins with https://<tenant>.webhook.office.com/webhookb2/...
5. Open /settings/integrations in Myncel and click Connect under Microsoft Teams.
6. Paste the webhook URL, give the channel a friendly label (purely cosmetic), and click Connect Teams.
7. Myncel posts a single confirmation card to verify wiring. From the Connected card you can press 👥 Test Card any time to re-test.

PagerDuty — on-call paging via Events API v2

PagerDuty is a native integration for on-call paging. When a critical alert fires or a PM goes overdue, Myncel triggers a PagerDuty incident on the service you choose, which then follows your existing on-call rotations and escalation policies. When the alert is resolved in Myncel, the matching PagerDuty incident is auto-resolved (deduplicated by a stable Myncel resource ID), so on-call engineers never have to manually clear our incidents.

Setup is a single 32-character Integration Key — no OAuth, no webhooks to configure on the PagerDuty side beyond the standard Events API V2 integration that ships in every PagerDuty service.

• Severity mapping — Myncel CRITICAL → PagerDuty critical (pages immediately), HIGH → error, WARNING/MEDIUM → warning, INFO/LOW → info (no page).
• Dedup keys — incidents are keyed by Myncel resource ID + event type. Re-firing the same alert updates the existing incident instead of opening a new one.
• Auto-resolve — when an alert is acknowledged or resolved in Myncel, a Resolve event is posted to PagerDuty so the on-call rotation does not get false re-pages.
• Routing-key rotation — to rotate, generate a new Events API V2 integration in the same PagerDuty service, paste the new key into Myncel, then delete the old integration in PagerDuty.

1. Sign in to PagerDuty → Services → pick the Service that should handle Myncel alerts (or create a new one named e.g. "Myncel — Production Floor").
2. Open the service → Integrations tab → click "+ Add a new integration".
3. Choose Events API V2 as the Integration Type → Add Integration.
4. Copy the Integration Key (a 32-character hexadecimal string).
5. In Myncel open /settings/integrations and click Connect under PagerDuty.
6. Paste the Integration Key, give the service a friendly label (e.g. "Production Floor"), and click Connect PagerDuty.
7. Myncel triggers + auto-resolves a single test incident on that service so you can verify the wiring in your PagerDuty timeline. From the Connected card you can press 🚨 Test Page any time.

ERP and accounting

Today, Myncel offers a native QuickBooks Online integration (in /settings/integrations → QuickBooks) for invoice and parts-cost sync. Other ERP systems can be connected via the public REST API and Webhooks. Native connectors for SAP, NetSuite, Microsoft Dynamics 365, Oracle Fusion, Sage, and Xero are on the roadmap.

• QuickBooks Online — native, OAuth-based, in /settings/integrations.
• Google Sheets — native, OAuth-based, for one-way data export to a sheet.
• Other ERPs — use the public REST API (/api/docs) plus Webhooks. We can share customer-built recipes for SAP and NetSuite — ask in /support.

Industrial protocols (IoT / SCADA / building automation)

For machine data we support every common industrial protocol through the Edge Gateway. Each protocol has its own setup page under /docs/edge-gateway with copy-pasteable YAML examples. Multiple protocols can target the same machine through one gateway instance.

• MQTT and MQTT-Sparkplug B — both broker and client mode; TLS supported.
• Modbus TCP — read holding registers, input registers, coils, discrete inputs.
• Modbus RTU (over TCP gateway or serial through the Edge Gateway).
• OPC-UA — secure subscription-based reads with certificate auth.
• Ethernet/IP (CIP) — Allen-Bradley / Rockwell PLCs.
• Siemens S7 — direct read from S7-300, S7-400, S7-1200, S7-1500.
• BACnet/IP — building automation, HVAC, lighting, energy meters.
• SNMP v2c / v3 — IT and network gear (UPS, switches, PDUs).
• REST / Webhook — for any system that can POST or be polled over HTTPS.
• OPC-DA (legacy) — supported via the Edge Gateway only.

Single sign-on (SSO) and SCIM provisioning

Myncel speaks SAML 2.0 for sign-in and SCIM 2.0 for user auto-provisioning, with full per-tenant configuration. Every Myncel organization has its own IdP slot — different tenants can plug into completely different identity providers without affecting each other, and your IdP credentials are scoped to your workspace alone. We have tested the integration end-to-end with Okta, Azure AD / Entra ID, Google Workspace, OneLogin, JumpCloud, and Ping Identity, and any standards-compliant SAML 2.0 / SCIM 2.0 IdP is expected to work.

There are two pieces. SAML SSO controls how users authenticate (browser redirects to your IdP, gets a signed assertion back, lands in Myncel). SCIM provisioning controls the user lifecycle (when an employee is hired, deactivated, role-changed, or renamed in the IdP, those changes flow into Myncel automatically). You can ship just SSO, just SCIM, or both — they are independent.

• SAML 2.0 (HTTP-POST binding) — signed AuthnRequest in, signed SAMLResponse with assertions back. Audience and signature validated; expired or unsigned assertions rejected.
• SCIM 2.0 (RFC 7643/7644) — bearer-token auth, full Users CRUD, PATCH partial-update grammar that every major IdP sends.
• JIT (just-in-time) provisioning — first SSO sign-in for a new email creates the Myncel user automatically. Combine with SCIM for full lifecycle automation.
• Group → role mapping — IdP "groups" attribute (or any attribute you point us at) is mapped to the OWNER / ADMIN / TECHNICIAN / OPERATOR / EMPLOYEE / MEMBER roles via case-insensitive substring match. Highest privilege wins.
• Per-tenant credentials — every org has its own IdP Entity ID, SSO URL, X.509 cert, and SCIM tokens. SuperAdmin (admin@myncel.com) can audit but not authenticate as the customer.

1. In Myncel, sign in as Owner or Admin and open Settings → SSO & SCIM. The page shows your SP-side URLs at the top: Entity ID / Audience, ACS URL, Metadata URL, and SCIM 2.0 base URL.
2. Open your IdP's admin console (Okta: Applications → Add Application; Azure AD: Enterprise applications → New application → Non-gallery; Google Workspace: Apps → Web and mobile apps → Add custom SAML app). Create a new app called "Myncel".
3. Paste the Myncel SP Entity ID and ACS URL into the IdP's "SP Entity ID" and "Reply URL / ACS URL" fields. Choose NameID format = email address. Optionally have the IdP send givenName, surname, and groups as additional attributes.
4. The IdP will give you back three values — its Entity ID (Issuer), its SSO URL, and its signing X.509 certificate (PEM). Paste these three into the matching fields under "SAML 2.0 Identity Provider" in Myncel and click Save SSO configuration.
5. Toggle "Enable SAML SSO". The /signin page now shows a second button, "Sign in with SSO (SAML)", that lands on /signin/sso where the user types your workspace slug and gets redirected to your IdP.
6. Optional but recommended for enterprise rollouts: toggle "Enforce SAML SSO". Now non-OWNER users in your org can no longer sign in with a password — they must use SSO. Owners are still allowed to password-sign-in as a break-glass.
7. For SCIM auto-provisioning: in the same Settings → SSO & SCIM page, scroll to "SCIM 2.0 Provisioning Tokens", give the token a label (e.g. "Okta production"), and click Generate new token. Copy the plaintext token NOW — it is shown once.
8. Back in your IdP, open the same Myncel app and switch on Provisioning. Paste the SCIM 2.0 Base URL and the bearer token into the IdP's SCIM screen. Set up the user attribute mappings (most IdPs auto-detect ours via /api/scim/v2/Schemas).
9. Test: in the IdP, create a test user, assign them to the Myncel app, and watch the user appear in /admin (or in the customer's /settings/team) within a few seconds. Deactivate the user in the IdP and watch them be soft-deleted in Myncel.

Public REST API and webhooks

Everything you can do in the Myncel UI you can also do via the public REST API. Use it to push your own equipment list in, automate work-order creation from your MES, or build custom dashboards. Auth is OAuth 2.0 client-credentials or scoped API keys. Full reference at /api/docs in your workspace.

Webhooks let Myncel POST to your endpoints when events happen (work-order created, alert fired, schedule due, comment added). Configure in Settings → Integrations → Webhooks. Payloads are signed with HMAC-SHA256 so you can verify authenticity.