Ga naar inhoud

Organisaties en klanten

Stel: je bent partner en bedient tien klanten. Elke klant moet eigen gebruikers, agents, kennis en gegevens hebben, en geen klant mag iets van een andere zien. In Core richt je dat in met organisaties: jouw eigen organisatie, en daaronder één organisatie per klant.

flowchart TB
    partner["Jouw organisatie"]
    partner --> a["Klant A"]
    partner --> b["Klant B"]
    partner --> c["Klant C"]
    b --> b1["Klant B, afdeling Zorg"]

Jouw eigen organisatie maakt je operator voor je aan. Je operator is Artific: de partij die de installatie draait. Alles daaronder maak je zelf: een organisatie per klant, en waar een klant dat nodig heeft nog een laag eronder.

Wat elke klantorganisatie zelf heeft

Onderdeel Wat dat betekent
Beheerders de personen die in de console inloggen en deze organisatie beheren
Sleutels de API-sleutels van de applicaties van deze klant, elk met eigen capabilities en policy
Agents, prompts, skills, tools de bibliotheek van deze klant
Kennis en gegevens collecties, indexen, grafen, datastores, geheugen, bestanden en gesprekken
Gebruik en limieten verbruik per sleutel en per persoon, en een kostenlimiet per maand
Audit en traces het spoor van wat er in deze organisatie gebeurde

Een sleutel van klant A bereikt alleen wat van klant A is. Vraagt die sleutel naar jouw organisatie of naar klant B, dan antwoordt Core 404, hetzelfde antwoord als voor iets wat niet bestaat.

Wat je als bovenliggende organisatie kunt

Je beheert elke organisatie onder de jouwe. Dat betekent:

  • een organisatie aanmaken, hernoemen, opschorten en verwijderen;
  • haar beheerders uitnodigen en haar sleutels registreren, roteren en intrekken;
  • het plafond van capabilities zetten: welke functies haar sleutels mogen aanzetten;
  • een kostenlimiet per maand zetten, in euro;
  • haar verbruik en auditspoor lezen, en verbruik van een hele tak optellen;
  • een markup zetten op wat zij voor verbruik betaalt (Modellen en routering);
  • onderdelen voorbehouden, zodat de eigen beheerders van de klant er niet bij kunnen:
    • Gebruikscijfers: het verbruik van de organisatie;
    • Auditspoor: de gebeurtenissen van aanroepen. Het spoor van beheerwijzigingen blijft van de klant;
    • Sleutelbeheer: sleutels, routeringsconfiguraties en routers wijzigen. Lezen blijft.

In de console open je een klantorganisatie vanuit Organisaties en werk je in haar onderdelen zoals haar eigen beheerders dat doen. Je ziet daar ook de inhoud van de klant: kennis, bestanden, datastores en traces. Houd daar rekening mee in je afspraken met de klant.

Met een API-sleutel ligt de grens anders. Een sleutel met de capability management beheert organisaties en leest hun inhoud niet via de gewone routes: geen kennis, prompts, bestanden of gesprekken van de klant. Zo'n sleutel kan wel een archief van een klantorganisatie aanvragen en downloaden, en dat archief bevat die inhoud (Je gegevens meenemen). Wil je applicatie in een klantorganisatie werken, dan registreert ze daar een sleutel en roept ze aan als die sleutel (Werken in een organisatie onder je).

Je eigen organisatie kun je niet opschorten of verwijderen, en je eigen plafond en kostenlimiet zet je niet zelf. Dat doet de organisatie erboven, en voor jouw organisatie is dat je operator. Waar een organisatie in de boom hangt, wijzigt alleen je operator, ook voor een organisatie onder je.

Het plafond van capabilities

Een capability is een functie die aan of uit staat, zoals knowledge of tooling. Elke organisatie heeft een plafond: de capabilities die haar sleutels mogen aanzetten. Een nieuwe organisatie begint met alles wat haar bovenliggende mag; je haalt weg wat een klant niet hoort te hebben.

Core controleert het plafond bij het instellen: wat je een klantorganisatie geeft, moet binnen het plafond van de organisatie direct erboven vallen. Versmal je later het plafond van een bovenliggende organisatie, dan geldt die versmalling vanaf de volgende aanroep voor elke organisatie eronder: een capability werkt alleen waar de organisatie en elke organisatie erboven haar toestaan. De opgeslagen plafonds eronder veranderen niet, dus verruim je het plafond erboven weer, dan krijgt elk ervan terug wat haar eigen plafond bevat, voor zover elke organisatie erboven dat toestaat.

Zet je een capability in het plafond uit, dan werkt dat bij de volgende aanroep voor elke sleutel van die organisatie en van elke organisatie eronder. De routes erachter antwoorden 404. Zie Sleutels, capabilities en policy.

Een policy werkt anders dan het plafond: de policy van een organisatie erboven bindt elke organisatie eronder bij elke aanroep, voor de soorten waarover ze een regel bevat, en eronder hoeft niets te worden aangepast (Policy).

De termen

Multi-tenancy betekent dat één installatie van Core meerdere klanten bedient en hun gegevens gescheiden houdt. In de API heet een organisatie een tenant; het id begint met ten_.

Isolatie is de manier waarop de gegevens van een organisatie in de database gescheiden worden. Je kiest bij het aanmaken een van twee, en die keuze ligt daarna vast:

Isolatie Wat het betekent Wanneer
Gedeeld (shared) de rijen van de organisatie staan in gedeelde tabellen; de database scheidt ze per organisatie op rijniveau de standaard; kies dit tenzij een klant iets anders eist
Schema (schema) de organisatie krijgt een eigen databaseschema en een eigen databaserol een klant eist dat zijn gegevens in eigen tabellen staan

Voor je applicatie maakt de keuze geen verschil: de API en de console werken bij beide hetzelfde. Elke organisatie kiest zelf, los van wat de organisatie erboven koos.

Database is een apart gegeven. Een organisatie staat standaard op dezelfde database als de organisatie erboven. Alleen je operator kan een organisatie een eigen database geven; alles wat je daarna onder die organisatie aanmaakt, komt dan ook op die database. Heeft een klant een eigen database nodig, vraag dat dan aan je operator voordat je de organisatie aanmaakt.

Hoe beheerders inloggen

De beheerders van een organisatie loggen standaard in de console in met een wachtwoord. Een organisatie kan ze ook laten inloggen met haar eigen identity provider -- OpenID Connect, Google Workspace of Microsoft Entra ID -- zodat haar mensen het account en de tweede factor gebruiken die ze op hun werk al hebben.

Zo'n provider maakt nooit een account aan. Hij laat alleen mensen in die de organisatie al als beheerder heeft uitgenodigd, herkend aan het e-mailadres dat de provider heeft geverifieerd, en alleen adressen in een e-maildomein waarvan de organisatie heeft bewezen dat het van haar is. Hij hoort bij die ene organisatie: organisaties eronder erven hem niet, en wie meer dan één organisatie beheert, blijft inloggen met een wachtwoord. Een beheerder deelt een inloglink die rechtstreeks naar de provider leidt, omdat de gewone inlogpagina de providers van geen enkele organisatie toont.

Dit staat los van de Identity providers die een organisatie registreert voor de mensen die haar applicaties via een sleutel gebruiken (Bouwen voor personen): die tokens wijzen een persoon aan bij een aanroep, nooit iemand in de console.

Stel er een in in de console of met een sleutel; wat de beheerder daarna ziet, staat in Inloggen.

Hoe het samenhangt

Een klantorganisatie erft geen bibliotheek en geen routering: geen agents, prompts, skills of tools, en geen routeringsconfiguraties of routers van de organisatie erboven. Wat je bij meerdere klanten wilt gebruiken, deel je met een publicatie.

Vijf dingen werken wel van boven naar beneden:

  • het plafond van capabilities begrenst wat je een klantorganisatie kunt geven;
  • een markup op alles eronder bepaalt de prijs die een klant ziet (Modellen en routering);
  • een nieuwe organisatie komt standaard op de database van de organisatie erboven;
  • een publicatie met Automatisch installeren wordt in elke nieuwe organisatie eronder geïnstalleerd (Delen en hergebruik);
  • een organisatie zonder eigen meldingsadres gebruikt dat van de dichtstbijzijnde organisatie erboven die er een heeft (Meldingen per mail).

Wat een sleutel binnen een organisatie bereikt, staat in Sleutels, capabilities en policy; wat je van een klantorganisatie ziet, in Inzicht.

Een klantorganisatie aanmaken

Dat kan op twee manieren, met hetzelfde resultaat:

Een nieuwe organisatie heeft de status Wordt ingericht tot Core klaar is. Je kunt in die tijd al sleutels registreren; ze werken zodra de status Actief is.

Verder

Tutorial: Richt een nieuwe klantorganisatie in.