Bygg dina egna appar i Fluit
Det där kalkylarket som bara en person förstår. Listan på whiteboarden. Kontrollen som alla ska komma ihåg. Snart beskriver ni det ni saknar, och AI:n bygger det åt er, inne i Fluit och kopplat till era kunder, ordrar och artiklar.
- Samma behörigheter och logg som resten av systemet
- Prova med riktig data innan något publiceras
- Slås på per företag, syns inte annars
Så är det tänkt
Från en mening till en app
Ni skriver vad ni behöver, som ni hade sagt det till en kollega. AI:n föreslår register, fält och statusar, och ni ser resultatet med er egen data innan något publiceras.
Ni
Vi behöver hålla koll på när våra mätinstrument ska kalibreras. Säg till två veckor innan, och visa vilka som är försenade.
Fluit
Mitt förslag:
- Registret Kalibreringar med nummerserie KAL
- Fälten instrument, ansvarig, senaste och nästa kontroll
- Statusarna Planerad, Försenad och Godkänd
- En funktion som varje morgon skapar en uppgift 14 dagar innan
Appar / Kalibrering
Kalibreringar
| Nummer | Instrument | Nästa kontroll | Status |
|---|---|---|---|
| KAL-0041 | Skjutmått 150 mm | 3 nov | Planerad |
| KAL-0042 | Momentnyckel 20–100 Nm | 28 okt | Försenad |
| KAL-0043 | Mikrometer 0–25 mm | 12 jan | Godkänd |
| KAL-0044 | Våg 30 kg | 19 nov | Planerad |
Illustration av hur det är tänkt att fungera, inte en skärmbild. Funktionen är under utveckling.
Kort svar
Vad det är, och var vi är
Med egna appar bygger ni det stöd er verksamhet behöver utöver standardfunktionerna. Det ni bygger blir en del av Fluit, inte ett program vid sidan av: posterna har behörigheter, aktivitetslogg och sök, syns i rapporterna och nås från API:t och AI-assistenten på samma sätt som en kundorder.
Funktionen är under utveckling. Den går inte att använda i dag, och pris och lanseringsdatum är inte satta. Den här sidan beskriver vad vi bygger.
Idéer
Vad skulle ni bygga?
Varje företag har några sådana här. Var och en är för liten för att bli en egen modul, och för viktig för att ligga i ett kalkylark.
”Vi vill veta när varje mätinstrument ska kalibreras nästa gång.”
”När en order släpps med mer än 15 procents rabatt vill säljchefen få veta det.”
”Vi lånar ut demoutrustning till kunder och tappar bort var den är.”
”Varje reklamation ska bedömas med foton och ett beslut innan vi krediterar.”
”Leverantörernas certifikat går ut och ingen märker det förrän revisionen.”
”Säljarna vill se kundens avtalade servicenivå direkt på ordern.”
Tre delar
Data, logik och sidor
Det mesta går att bygga utan kod. Ett register med fält och statusar ger en färdig lista och detaljsida. Kod behövs först när logiken kräver det, och då skriver AI:n den.
Egen data
Egna register med de fält, statusar och nummerserier ni behöver. Och egna fält på det som redan finns, som kunden, artikeln eller ordern.
Egen logik
Funktioner som körs när något händer, på schema eller när någon trycker på en knapp. En order släpps och en post skapas i ert register, till exempel.
Egna sidor
Listor, formulär och detaljsidor av samma delar som resten av Fluit. Eller en flik på kundkortet och en knapp på ordern, precis där ni behöver dem.
Inbyggt från början
Ett eget register fungerar som resten av Fluit
Det är skillnaden mot en app byggd vid sidan av. Ingen behöver koppla ihop något i efterhand.
Behörigheter
Varje eget register får läs-, skriv- och raderingsbehörighet som era befintliga roller styr. Den som saknar behörighet ser varken menyposten eller posterna.
Aktivitetslogg
Ändringar loggas fält för fält, precis som på en kundorder. Ni ser vem som ändrade vad och när.
Sök, kommentarer och bilagor
Posterna hittas i den vanliga sökningen, och ni kommenterar och bifogar filer på samma sätt som överallt annars.
Rapporter och Power BI
Egna register går att använda i egna rapporter och i OData-flödet, så att de kan ställas mot order, kunder och artiklar.
API och webhooks
Registren nås genom det publika API:t, och en ny eller ändrad post kan skicka en webhook till ett annat system.
AI-chatten och MCP
Assistenten i Fluit, och den ni kopplat via MCP, kan läsa och skapa poster i era register med samma behörigheter som en användare.
Så går det till
Från beskrivning till publicerad app
-
1
Ni beskriver behovet
I klartext, till exempel att ni vill hålla koll på kalibreringen av mätinstrument, med ett datum för nästa kontroll och en status.
-
2
AI:n föreslår ett utkast
Register, fält, statusar, funktioner och sidor. Förslaget kontrolleras av servern, och AI:n rättar det som inte håller.
-
3
Ni provar med er riktiga data
Förhandsvisningen läser era riktiga poster utan att ändra något. Funktioner kan testköras så att ni ser vad de skulle skriva, utan att det skrivs.
-
4
Ni publicerar, och kan backa
Det som publiceras blir en version som inte ändras i efterhand. Blev något fel går ni tillbaka till förra versionen, och posterna ligger kvar.
Ramarna
Vad en app får göra, och vad den inte får
Kod som en AI har skrivit ska inte kunna mer än den som bad om den. Så här är gränserna dragna.
En app får aldrig mer än en användare
Appen har en egen identitet med en roll som en administratör godkänner, på samma sätt som när ni kopplar en ny tjänst. Allt den gör går genom samma behörighetskontroller som när en person arbetar i webbläsaren.
Skrivningar går genom systemets egna funktioner
Läsning får vara fri inom det ni har rätt att se. När en app ändrar något sker det med samma valideringar och samma logg som i gränssnittet. Ingen genererad kod skriver direkt i databasen.
Koden körs avskild
Funktioner körs i en egen miljö utan nätverk och utan databas. De når Fluit bara via API:t, och varje körning har en gräns för tid, minne och antal anrop.
Ni bestämmer hur självständig den får vara
En funktion kan bara rapportera, föreslå ändringar som någon godkänner, eller utföra dem direkt. Varje körning sparas i en körlogg med de anrop den gjorde.
Vanliga frågor
Om egna appar
Kan vi använda det i dag?
Inte ännu. Funktionen är under utveckling och byggs i steg: först egna register och fält, sedan logiken, därefter egna sidor och byggmiljön med AI. Vill ni vara med tidigt, hör av er så berättar vi var arbetet står.
Vad kommer det att kosta?
Det är inte bestämt. Vi sätter priset när vi har sett hur funktionen används hos de första kunderna, och det blir klart innan funktionen lanseras.
Måste vi kunna programmera?
Nej. Ett eget register med fält och statusar ger en färdig lista och detaljsida utan en rad kod. Kod behövs först när logiken kräver det, och då är det AI:n som skriver den och servern som kontrollerar den innan något publiceras.
Vem får bygga appar?
Administratören, och de roller ni ger en särskild behörighet för att bygga. Att godkänna vad en app får göra i systemet kräver alltid en administratör.
Vad händer med datan om vi tar bort en app?
Posterna ligger kvar och går att läsa och exportera. De raderas först när en administratör uttryckligen bestämmer det.
Hur skiljer sig en app från en AI-rutin?
En AI-rutin är en instruktion till assistenten om hur en uppgift ska göras. En app lägger till nya delar i själva systemet: register, logik och sidor som finns kvar och används av alla med behörighet, även när ingen pratar med assistenten.
Märks det för den som inte använder funktionen?
Nej. Den slås på per företag. Den som inte slår på den får inga nya menyposter och inga nya verktyg i AI-kopplingen.
Det som finns i dag
- AI-rutiner: beskriv ert arbetssätt i text och låt assistenten följa det.
- MCP-kopplingen: låt er egen AI-assistent arbeta direkt mot Fluit.
- API och webhooks: bygg integrationer mot Fluit med REST, webhooks och OData.
Vad är det ni saknar?
Berätta vad ni löser i ett kalkylark i dag. Vi tar gärna in några företag som får prova funktionen innan den släpps.