Note spese e Okta: integrazione per IT manager e sviluppatori
Le aziende che usano Okta come identity provider vogliono che ogni SaaS del loro stack sia allineato al ciclo di vita dell'utente: provisioning, deprovisioning, accessi centralizzati, nessuna password locale da gestire. fees si integra con Okta portando i dati delle note spese approvate nel flusso identità e contabile già governato dall'IT.
Come arrivano i dati delle note spese in Okta
L'integrazione tra fees e Okta è già realizzata: in fase di onboarding viene calata sulla configurazione specifica dell'azienda, adattando campi, causali e codifiche al modello dati in uso. Ci sono due strade operative. La prima è un tracciato di export contabile (CSV, XML o TXT) configurato sui campi che Okta si aspetta in import: utile quando il flusso è batch e segue cadenze definite (giornaliera, settimanale). La seconda è l'API fees Can: le spese approvate viaggiano in JSON verso Okta in modo più continuo, adatto a chi vuole ridurre la latenza tra approvazione e registrazione. La scelta dipende dall'architettura esistente e si definisce durante l'onboarding.
Mappatura dei dati: centri di costo, commesse e anagrafiche
Il punto critico di qualsiasi integrazione è la mappatura: i codici che fees usa internamente (centri di costo, commesse, causali di spesa, anagrafiche dipendenti) devono corrispondere esattamente agli identificatori che Okta si aspetta. In onboarding si costruisce questa tabella di corrispondenza: l'IT fornisce il dizionario dei codici attivi in Okta, il team fees configura i tracciati o i payload JSON di conseguenza. Se l'azienda usa Okta anche per sincronizzare le anagrafiche HR verso altri sistemi, la stessa logica si applica: l'utente in fees corrisponde all'identità Okta, e l'attivazione o disattivazione dell'account segue il ciclo di vita gestito dall'IT.
Come arrivano i dati delle note spese in Okta
Per avviare l'integrazione in modo efficiente, il reparto IT deve arrivare all'onboarding con tre elementi chiari: la lista dei campi obbligatori che Okta richiede nei flussi di import (formato, lunghezza, codifiche); il dizionario aggiornato dei centri di costo e delle anagrafiche attive; e la decisione su quale modalità di trasferimento dati si adatta meglio all'infrastruttura esistente (export batch o API JSON). Non serve costruire nulla da zero: l'integrazione esiste e il lavoro in onboarding è di configurazione e allineamento, non di sviluppo. Eventuali specificità — strutture organizzative complesse, più legal entity, codifiche particolari — vengono gestite caso per caso durante quella fase.
Q&A
Come si gestisce il deprovisioning in fees quando un utente viene disattivato in Okta?
Cosa deve fornire l'IT per configurare la mappatura dei campi?
fees supporta strutture multi-entità con più configurazioni Okta distinte?
