Integrazioni disponibili: cosa fanno e cosa richiamano
Questa pagina è un riferimento: elenca le integrazioni (connettori) disponibili oggi in ServiceBoard e, per ciascuna, a cosa serve, quale servizio esterno richiama (e con che tipo di API), se lavora in sola lettura o scrive anche sul sistema remoto, e quali dati sincronizza. Ti serve quando devi rispondere a domande di trasparenza sui dati (anche per GDPR), decidere cosa collegare o fare troubleshooting su una sincronizzazione.
Come collegare un'integrazione
Le integrazioni si collegano da Impostazioni › Connettori (menu a sinistra, solo per amministratori, gruppo Dati & Sync). Selezioni la card del connettore e segui la procedura guidata: credenziali, clienti (auto-discovery) e campi custom.
- Per il flusso base di collegamento e sincronizzazione vedi Collegare le sorgenti dati.
- Per collegare più account dello stesso tipo (per esempio due HaloPSA) vedi Connettori: più istanze dello stesso tipo.
Nelle tabelle qui sotto trovi indicati gli endpoint pubblici noti solo a scopo di trasparenza: le credenziali non compaiono mai e restano cifrate (vedi Sicurezza dei dati).
Catalogo delle integrazioni
Legenda della colonna Accesso: Sola lettura = ServiceBoard legge soltanto; Legge e scrive = può anche modificare dati sul sistema remoto (nei limiti indicati).
Nota: la maggior parte dei connettori è in sola lettura. Le eccezioni che scrivono sul sistema remoto sono poche e circoscritte: HaloPSA e Atera fanno write-back sui ticket (creano/aggiornano/chiudono), Pipedrive carica il PDF dell'offerta sul deal e Microsoft 365 scrive solo nelle azioni di remediation con consenso. In dubbio, guarda la colonna Accesso.
PSA / Helpdesk
Portano i ticket dei sistemi di assistenza nel modello canonico di ServiceBoard.
| Connettore | Cosa fa | Servizio esterno + API | Accesso | Dati sincronizzati |
|---|---|---|---|---|
| HaloPSA | Sincronizza i ticket di supporto (via report HTML e API) arricchendoli con note di chiusura, SLA e clienti | HaloPSA API — REST, OAuth2 client_credentials ({baseUrl}/auth/token, {baseUrl}/api/Tickets, {baseUrl}/api/Report, /api/Actions, /api/Client, /api/SLA) |
Legge e scrive: write-back live sul ticket remoto (stato, priorità, note, chiusura) via POST /api/Tickets e POST /api/Actions |
ticket, clienti, note/azioni ticket, SLA, workday/orari, note di chiusura |
| Autotask PSA | Sincronizza ticket, aziende e device con pattern metadata-first (picklist/lookup risolti una volta) e supporto UDF; scopre la zona API del cliente prima del sync | Autotask REST API v1.0 — REST, 3 header ApiIntegrationCode/UserName/Secret (bootstrap zona su zoneInformation, poi .../atservicesrest/v1.0/{Entity}, POST /Tickets/query) |
Sola lettura per il sync (i POST sono solo /query e /query/count). Webhook e write-back sono in roadmap |
ticket, clienti (Companies), device, risorse/tecnici (Resources), UDF/custom fields, note ticket |
| Freshservice | Sincronizza ticket di supporto e aziende con paginazione automatica | Freshservice API v2 — REST, Basic auth ({baseUrl}/api/v2/tickets, updated_since per l'incrementale) |
Sola lettura | ticket, aziende/clienti (companies), requester/responder/department/group |
RMM
Sistemi di monitoraggio e gestione remota: portano ticket, organizzazioni e (dove previsto) device e patch.
| Connettore | Cosa fa | Servizio esterno + API | Accesso | Dati sincronizzati |
|---|---|---|---|---|
| NinjaOne (RMM) | Sincronizza i ticket del modulo Ticketing e l'elenco organizzazioni; è anche sorgente device per l'inventario Oggetti | NinjaOne REST API v2 — REST, OAuth2 client_credentials → Bearer ({base}/ws/oauth/token, /v2/ticketing/ticket, /v2/organizations) |
Sola lettura. Il modulo Ticketing è opzionale (solo piani che lo includono); servono permessi Ticketing:Read + Monitoring:Read |
ticket, organizzazioni/clienti, device (per inventario Oggetti/CMDB, famiglia objects_) |
| Atera | Sincronizza ticket, clienti, agent/device e patch da Atera (RMM/PSA) | Atera REST API v3 — REST, API key in header x-api-key (https://app.atera.com/api/v3, /tickets, customers, agents, patch) |
Legge e scrive: creazione, aggiornamento, chiusura ed eliminazione ticket (POST/PUT/DELETE) |
ticket, clienti (customers), agent/device, patch installate/disponibili, custom fields, commenti ticket |
Backup
| Connettore | Cosa fa | Servizio esterno + API | Accesso | Dati sincronizzati |
|---|---|---|---|---|
| NinjaOne Backup SaaS | Porta lo stato dei backup cloud-to-cloud (Microsoft 365/Cloud) per ogni organizzazione: dati org-level aggregati + dettaglio per-mailbox e per-servizio | NinjaOne Backup SaaS API "Sub-reseller" — REST, header X-Reseller-Token + X-Access-Token (base https://<host-portale-saas>/api, /status, /users, /onedrives, /sharepoints/domains, /teams_and_groups/domains) |
Sola lettura (modello "DeepScan") | organizzazioni backup (seat, storage, shared mailbox), mailbox (stato, ultimo backup, storage, errori), OneDrive, calendari, contatti, task, siti SharePoint, Teams & gruppi |
Le credenziali del backup sono separate da quelle del connettore RMM NinjaOne: non riusano lo stesso token.
Identità / Microsoft 365
| Connettore | Cosa fa | Servizio esterno + API | Accesso | Dati sincronizzati |
|---|---|---|---|---|
| Microsoft 365 (Microsoft Graph) | Read+sync dei tenant Microsoft 365 (app-only): identità/MFA, licenze, storage SharePoint/OneDrive, sicurezza, mailbox e audit; alimenta card cliente, famiglia widget m365_, AI e remediation |
Microsoft Graph — REST v1.0 app-only/client credentials → Bearer (base https://graph.microsoft.com/v1.0, token su login.microsoftonline.com/{tenant}/oauth2/v2.0/token, /organization, /subscribedSkus, /security/*, /auditLogs/*) |
Legge e scrive, ma solo in remediation con consenso: di base il client Graph è read-only; le azioni di remediation (blocca/sblocca utente, revoca sessioni, rimuovi licenza) richiedono i consensi Graph dedicati, il permesso manage_settings, doppio audit e falliscono in modo controllato se non autorizzate |
utenti/identità + stato MFA, licenze/SKU, storage SharePoint/OneDrive (con trend), alert di sicurezza, sign-in, Secure Score, mailbox/shared mailbox, audit storicizzato con retention, scadenze/rinnovi licenze (inserimento manuale) |
Richiede un prerequisito esterno (app Azure AD con consensi/GDAP). Vedi la guida Microsoft 365. Nota: questa è l'integrazione dati; è diversa dal login Accesso con Microsoft (SSO) più in basso.
VoIP
| Connettore | Cosa fa | Servizio esterno + API | Accesso | Dati sincronizzati |
|---|---|---|---|---|
| KalliopePBX (Centralino VoIP) — Fase 1 / parziale | Consultazione read-only dello stato code e operatori (membri dinamici, pause) del centralino | KalliopePBX REST API — REST, header custom monouso X-authenticate (digest sha256 + salt + nonce) (base = radice API del PBX in HTTPS, {baseUrl}/rest/salt/{dominio}, /rest/operation/queue) |
Sola lettura in questa fase | stato code (queue): membri dinamici, pause operatori, penalty |
Attenzione: il registro chiamate (CDR) e le azioni operative di scrittura (DND, inoltri, pausa/membro coda) non sono ancora completati (Fase 2 / TODO). Le route sono riservate agli amministratori.
Attenzione: il connettore KalliopePBX è in Fase 1: oggi legge soltanto lo stato di code e operatori. Il registro chiamate (CDR) e le azioni operative di scrittura (DND, inoltri, pausa/membro coda) non sono ancora attivi e arriveranno in una fase successiva.
CRM / Offerte
| Connettore | Cosa fa | Servizio esterno + API | Accesso | Dati sincronizzati |
|---|---|---|---|---|
| Pipedrive (CRM) | Supporta il modulo Offerte: prefill delle offerte dai deal, lettura di deal/organizzazioni/prodotti-listino e push del PDF dell'offerta sul deal | Pipedrive API v1 — REST, token in header x-api-token (https://azienda.pipedrive.com, /api/v1/deals, organizations, prodotti/listino, POST /api/v1/files) |
Legge e scrive: legge deal/organizzazioni/prodotti ma scrive file/PDF sul deal (pushFileToDeal) |
deal/trattative, organizzazioni, prodotti e prezzi (listino), file/allegati (PDF offerta caricato sul deal) |
Import (da endpoint o file)
| Connettore | Cosa fa | Servizio esterno + API | Accesso | Dati sincronizzati |
|---|---|---|---|---|
| Web API (JSON) generico | Connettore ticket generico da una qualsiasi HTTP JSON API: indichi l'endpoint lista, il JSON-path dell'array di record e mappi i campi sul modello canonico Ticket | HTTP JSON API arbitraria configurata da te — REST/HTTP JSON, auth a token in header o ?token= (baseUrl + listPath, recordsPath, fieldMap, paginazione opzionale) |
Sola lettura (la v1 non fa write-back né OAuth) | ticket (modello canonico, id esterno, customFields via path) |
| CSV Upload | Importa ticket da file CSV o Excel (Import universale) con mappatura colonne visuale e auto-detect; parsing, mapping e validazione lato client e lato server | Nessun servizio esterno: è un import da file | Sola lettura (import) | ticket (dal file CSV/Excel) |
Il CSV Upload non chiama alcun servizio esterno e non salva credenziali: leggi solo il file che carichi.
SSO (accesso utente)
| Connettore | Cosa fa | Servizio esterno + API | Accesso | Dati sincronizzati |
|---|---|---|---|---|
| Accedi con Microsoft (SSO OIDC) | Single Sign-On "Accedi con Microsoft" via OpenID Connect (Authorization Code) per l'autenticazione utente, con pinning issuer/tenant e verifica firma dell'id_token |
Microsoft Entra ID (OIDC v2) — OIDC / OAuth2 Authorization Code (base https://login.microsoftonline.com, {tenant}/oauth2/v2.0/authorize e /token, scope minimo openid email profile, JWKS per la firma) |
Sola lettura: solo autenticazione, nessun accesso a Microsoft Graph né ad alcun dato di business | identità utente / email (claim dell'id_token; nessun dato aziendale) |
Lo scope OIDC è il minimo (openid email profile): serve solo a far accedere l'utente. È diverso dall'integrazione dati Microsoft 365 qui sopra. Vedi Accesso con Microsoft (SSO).
Sicurezza dei dati
Nota: tutte le credenziali (token, API key, client secret, password e URL sensibili) sono cifrate a riposo con AES-256-GCM, non vengono mai loggate e non lasciano mai il server: al frontend arrivano al massimo indicatori del tipo "credenziale presente".
Tutte le integrazioni condividono le stesse protezioni di base:
- Credenziali cifrate — token, API key, client secret, password e URL sensibili sono cifrati a riposo con AES-256-GCM, non vengono mai loggati e non sono mai esposti al frontend (le API restituiscono al massimo indicatori del tipo "credenziale presente").
- Protezione anti-SSRF sugli URL — gli URL di destinazione (per esempio i
baseUrlon-prem) sono filtrati per impedire richieste verso indirizzi non consentiti come i metadata cloud e il loopback; gli host on-prem/VPN legittimi restano ammessi. - Multi-istanza — per la maggior parte dei connettori puoi collegare più account dello stesso tipo, ognuno con credenziali e clienti separati (vedi Connettori: più istanze dello stesso tipo). Ogni istanza usa le proprie credenziali, sempre server-side.
- Scope per-tenant — i dati sono associati al tenant e restano isolati; le integrazioni popolano dati che poi seguono lo stesso ambito (scope) applicato ovunque nella piattaforma.
Domande frequenti
Le integrazioni sono in sola lettura? Dipende dal connettore: la maggior parte è in sola lettura, ma alcune scrivono. HaloPSA e Atera fanno write-back sui ticket; Pipedrive carica il PDF dell'offerta sul deal; Microsoft 365 scrive solo nelle azioni di remediation, con i consensi e i permessi dedicati. Autotask, Freshservice, NinjaOne (RMM), NinjaOne Backup, il Web API generico, il CSV Upload, KalliopePBX (in questa fase) e l'SSO sono in sola lettura. Controlla la colonna Accesso nel catalogo.
Dove vanno i miei dati?
I dati letti dai sistemi collegati vengono importati in ServiceBoard e restano nel tuo tenant, con lo scope applicato in tutta la piattaforma. I servizi esterni richiamati sono quelli elencati nel catalogo (per esempio HaloPSA API, Microsoft Graph, Pipedrive API v1): la pagina serve proprio a documentare cosa viene richiamato per finalità di trasparenza e GDPR. Le credenziali di accesso a quei servizi sono cifrate e non lasciano mai il server.
Posso collegare due account dello stesso tipo? Sì: la maggior parte dei connettori è multi-istanza. Colleghi più account dello stesso tipo (per esempio due HaloPSA o due Freshservice), ciascuno con credenziali, prefisso e clienti propri. I dettagli sono in Connettori: più istanze dello stesso tipo.
Perché il connettore KalliopePBX mostra meno funzioni? Perché è in Fase 1: oggi legge solo lo stato di code e operatori. Il registro chiamate (CDR) e le azioni operative di scrittura sono previsti in una fase successiva.
Il modulo Ticketing di NinjaOne non porta ticket: perché? È opzionale e disponibile solo sui piani che lo includono. Se manca, il connettore non riceve ticket (situazione gestita, senza errori) ma continua a fornire organizzazioni e device.