# Integrationer og notifikationer Alunta har flere slags forbindelser. En betalings- eller regnskabsintegration flytter eller synkroniserer forretningsdata, en tredjepartsapp reagerer via API og webhooks, Slack og email informerer teamet, og Radar giver signaler om kvalificerede virksomhedskunder. Vælg den arbejdsgang, der passer til formålet. ## Aktivér en tredjepartsintegration Åbn **Tredjepartsintegrationer** eller marketplace, vælg en app, og læs hvilke indstillinger den kræver. Aktivér den, udfyld indstillingerne, og send en test-webhook hvis funktionen tilbyder det. En app, der kan ses i marketplace, er ikke nødvendigvis aktiv for dit team. Efter aktivering kan indstillinger ændres eller forbindelsen afbrydes fra appens side. En ejer eller administrator kan forhåndsvise og sende en forbindelsestest eller bevidst vælge et eksempel på en af integrationens hændelser. Forbindelsestesten er standardvalget. Leveringen sker i baggrunden; vent på HTTP-resultatet, før du vurderer forbindelsen. Eksempler bruger fiktive ressourcer og opretter ingen forretningsdata i Alunta, men modtageren kan behandle eksemplet. Testleverancer holdes uden for driftsstatistik og fejlalarmer. Der kan accepteres fem testafsendelser eller genafsendelser pr. minut pr. konto; marketplace-modtagerens kapacitetsgrænse gælder også. ## Slack og teamnotifikationer Forbind Slack, vælg det workspace og den kanal, som den tilsluttede app kan se og skrive i, og send en test. Vælg derefter de hændelser, teamet vil modtage. Hvis kanalen mangler, skyldes det ofte kanaladgang eller at forbindelsen peger på et andet workspace. Slack-notifikationer er teambeskeder; de er ikke kundemails eller webhook-events. ## Regnskab og betalingsstatus Regnskabsintegrationer som e-conomic, Dinero og Billy har deres eget dokumentlayout og egne synkroniseringsstatusser. En fejl i integrationsoversigten betyder ikke automatisk, at en faktura er ubetalt. Åbn den viste fejl, følg den relevante vejledning, og kontrollér derefter status på dokumentet. Ikke alle fejl har en genforsøgshandling. ## Radar Radar undersøger relevante offentlige virksomhedsoplysninger for kvalificerede kunder. Et signal er en observation, som kan kræve opfølgning; det er ikke en automatisk afgørelse om kunden. Åbn signalet, læs historikken, og kontrollér kilden før du ændrer et abonnement eller kontakter kunden. Informationsfund kan gemmes uden at blive sendt som alarm. ## Hjælp med en konkret fejl **Få hjælp** ved en integrationsfejl, webhooklevering eller faktura åbner Support med en reference til problemet. Herfra kan du kontakte Alunta eller tage et forberedt spørgsmål med til din egen AI. Hvis AI-forbindelsen mangler, fortsætter opsætningen på **Min AI** med referencen bevaret. Du behøver ikke forbinde en AI for at få personlig hjælp. På selve Support-siden skal du ikke vælge et område. Har du en forbundet AI, får du ét forberedt spørgsmål, og AI'en ser selv på de relevante områder med de værktøjer, den har adgang til. "Få hjælp"-knapper placeret ved et bestemt område bærer stadig dette område med. Når et spørgsmål indeholder en supportreference, skal agenten først vælge den rigtige Alunta-konto og derefter kalde `get_support_context` med hele referencen. Referencen giver ikke nye rettigheder. Værktøjet læser den aktuelle gemte status og en begrænset forklaring; det sender ikke rå fejlbeskeder, webhook-payloads, headers eller svar fra udbyderen til AI. Følg de tilladte værktøjer og begrænsninger i svaret for at undersøge videre. Et generelt emne, eksempelvis sundhedstjek, er ikke en diagnose af en bestemt hændelse. Vis forskellen mellem det, der er observeret, og en mulig forklaring. En fejl, der ikke vises på dashboardet, er ikke nødvendigvis løst, og gemte oplysninger beviser ikke udbyderens aktuelle tilstand. Hvis referencen ikke længere kan læses, skal brugeren åbne problemet i Alunta igen eller kontakte support. Hjælpeflowet genforsøger ikke betalinger eller webhooks og ændrer ikke data. ## Typiske begrænsninger En forbindelse skal være aktiveret og korrekt konfigureret for det konkrete team. En synlig app er ikke det samme som en aktiv app. Testbeskeden eller leveringsloggen viser kun, at en besked blev forsøgt leveret; din egen integration skal stadig håndtere dubletter og fejl. Brug teamets aktuelle appstatus, før du bygger en arbejdsgang på en dokumenteret mulighed.