> Continue procesverbetering > Incidentbeheer > Freshservice > Datatemplate

Jouw datatemplate voor incidentbeheer

Freshservice

Attributen voor incidentbeheer (19) Incidentbeheeractiviteiten (14) Extractiegidsen (3)

Jouw datatemplate voor incidentbeheer

Deze template helpt je om je data voor te bereiden op een goede analyse van incidentbeheer. Je ziet welke attributen je moet verzamelen, welke activiteiten je moet volgen en hoe je deze informatie uit je bronsysteem haalt. Gebruik deze bron om je datavoorbereiding efficiënter te maken.

Aanbevolen attributen om te verzamelen
Belangrijke activiteiten om te volgen
Richtlijnen voor data-extractie

Nieuw met event logs? Leer hoe je een process mining-event log maakt.

Template downloaden

Attributen voor incidentbeheer

Dit zijn de aanbevolen datavelden voor je event log voor een volledige analyse van je incidentbeheerproces.

5 Verplicht 7 Aanbevolen 7 Optioneel

	Naam	Beschrijving
	Incident-ID IncidentId	De unieke identificatie van elk incidentrecord. Deze dient als primaire sleutel om de volledige levenscyclus van het incident te volgen.
Beschrijving De Incident-ID vormt de basis van incidentbeheeranalyse. Deze werkt als de Case-ID en koppelt alle gerelateerde activiteiten, timestamps en wijzigingen in attributen aan één samenhangend proces. In process mining is elke vermelding in het event log gekoppeld aan een Incident-ID. Zo kun je de end-to-end-procesflow van elk incident reconstrueren. Dit is essentieel voor het berekenen van doorlooptijden, het analyseren van procesvarianten en het identificeren van bottlenecks die specifiek zijn voor afzonderlijke cases. Zonder unieke identificatie zou het onmogelijk zijn om verschillende incidenten van elkaar te onderscheiden en hun route van melding tot oplossing te analyseren. Waarom dit belangrijk is Deze identificeert elk incident uniek, zodat je de levenscyclus van aanmaak tot sluiting end-to-end kunt volgen en analyseren. Waar je het vindt Dit is de primaire identificatie voor een ticket. Deze is beschikbaar via de Freshservice Tickets API als het veld 'id' in het ticketobject. Voorbeelden INC-10234INC-10235INC-10236
	Activiteitsnaam ActivityName	De naam van de specifieke bedrijfsactiviteit of gebeurtenis die op een bepaald moment in de levenscyclus van het incident plaatsvond.
Beschrijving De Activiteitsnaam beschrijft één stap of gebeurtenis in het incidentbeheerproces, zoals 'Incident Assigned to Group', 'Status Changed to Pending' of 'Incident Resolved'. Deze activiteiten worden afgeleid uit wijzigingen in de data van het incident in de loop van de tijd. Dit attribuut is belangrijk voor process mining, omdat het de nodes in de ontdekte procesmap definieert. Door de volgorde en frequentie van deze activiteiten te analyseren, kunnen organisaties het werkelijke proces voor incidentoplossing visualiseren, veelvoorkomende routes herkennen, afwijkingen van de standaardprocedure detecteren en herwerklussen zoals frequente her toewijzingen opsporen. Waarom dit belangrijk is Dit definieert de stappen in de procesmap, zodat je de flow voor incidentoplossing, bottlenecks en afwijkingen kunt visualiseren en analyseren. Waar je het vindt Dit attribuut is geen rechtstreeks veld in Freshservice, maar wordt afgeleid uit wijzigingen in ticketeigenschappen zoals status, prioriteit, agent- of groepstoewijzing en het toevoegen van notities. Voorbeelden Incident gemeldIncident toegewezen aan groepOplossingsnotitie toegevoegdIncident opgelost
	Bronsysteem SourceSystem	Het systeem waaruit de data is geëxtraheerd, meestal 'Freshservice'.
Beschrijving Dit attribuut identificeert de herkomst van de data. In deze context is de waarde steeds 'Freshservice', maar het veld is belangrijk in omgevingen waar data uit meerdere systemen wordt gecombineerd voor een integraal procesoverzicht. Het opnemen van het attribuut Bronsysteem is een goede werkwijze voor datagovernance en traceerbaarheid. Het maakt duidelijk waar de data vandaan komt. Dat is belangrijk voor validatie, foutopsporing en een eventuele uitbreiding van het process-miningproject met andere service-management- of bedrijfssystemen. Waarom dit belangrijk is Dit zorgt voor traceerbaarheid en governance van de data door de herkomst van de incidentbeheerdata duidelijk vast te leggen. Waar je het vindt Dit is meestal een statische waarde die tijdens het data-transformatieproces (ETL) wordt toegevoegd om de dataset te labelen. Voorbeelden FreshserviceFreshservice-EUFreshservice-PROD
	Eventtimestamp EventTimestamp	De exacte datum en tijd waarop de activiteit of gebeurtenis plaatsvond.
Beschrijving De Eventtimestamp, of Start Time, markeert het precieze moment waarop een activiteit plaatsvond. Elke activiteit in de levenscyclus van het incident, van aanmaak tot sluiting, heeft een bijbehorende timestamp. Dit attribuut vormt de basis voor alle tijdgebaseerde process-mininganalyses. Je gebruikt het om gebeurtenissen chronologisch te ordenen, de duur tussen activiteiten te berekenen, de totale doorlooptijd van een case te meten en wachttijden te analyseren. Het vormt ook de basis voor dashboards die SLA-prestaties, vertragingen bij overdrachten en totale oplostijden volgen. Waarom dit belangrijk is Dit geeft de chronologische volgorde van gebeurtenissen en is essentieel voor het berekenen van doorlooptijden, het analyseren van cyclustijden en het begrijpen van procesprestaties. Waar je het vindt Dit wordt afgeleid uit verschillende timestampvelden in Freshservice, zoals 'created_at', 'updated_at' en timestamps in de conversatie- of auditlogs van het ticket. Voorbeelden 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	Laatste data-update LastDataUpdate	De timestamp die aangeeft wanneer de data voor dit proces voor het laatst is vernieuwd of geëxtraheerd.
Beschrijving Dit attribuut bevat een timestamp voor het moment waarop de volledige dataset voor het laatst vanuit het bronsysteem is bijgewerkt. Het is een metadataveld dat op de hele dataset van toepassing is en niet op afzonderlijke gebeurtenissen, maar wordt vaak voor consistentie op eventniveau opgenomen. Bij analyses helpt deze informatie om te bepalen hoe actueel de data is en welke periode door de dashboards en KPI's wordt afgedekt. Zo weten gebruikers hoe recent de inzichten zijn en of de nieuwste incidenten waarschijnlijk in de analyse zijn opgenomen. Waarom dit belangrijk is Dit informeert gebruikers over de actualiteit van de data, zodat duidelijk is welke periode door de analyse wordt afgedekt. Waar je het vindt Dit is een metadatatimestamp die tijdens het data-extractieproces (ETL) wordt gegenereerd. Voorbeelden 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Doeltijd voor resolutie-SLA ResolutionSlaTargetTime	De timestamp waarop het incident volgens het SLA-beleid opgelost moet zijn.
Beschrijving Dit attribuut bevat de specifieke datum en tijd die als deadline voor het oplossen van een incident geldt. Dit doel wordt bepaald door het Service Level Agreement (SLA)-beleid dat op het ticket van toepassing is en hangt meestal af van factoren zoals prioriteit. Deze doeltijd is nodig voor het berekenen van de KPI 'SLA Adherence Rate' en voor het dashboard 'SLA Performance Dashboard'. Door de werkelijke timestamp van de oplossing met dit doel te vergelijken, kun je bepalen of een incident op tijd is opgelost of de SLA heeft overschreden. Dit is de basis voor het meten van naleving van serviceniveaus. Waarom dit belangrijk is Dit geeft de deadline voor de oplossing en is nodig om SLA-naleving te berekenen en incidenten met risico op overschrijding te identificeren. Waar je het vindt Beschikbaar in de Freshservice Tickets API als de velden 'fr_due_by' (eerste reactie) en 'due_by' (oplossing). Voorbeelden 2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-05T17:00:00Z
	Incidentcategorie IncidentCategory	De categorie waarmee het incident wordt ingedeeld, zoals Hardware, Software of Network.
Beschrijving Incidentcategorie biedt een manier om incidenten in te delen op basis van het type probleem dat wordt gemeld. Deze hiërarchische indeling helpt om het incident naar het juiste team te routeren en is belangrijk voor trendanalyses. Dit attribuut wordt gebruikt in het dashboard 'Incident Categorization Accuracy' om te analyseren of een onjuiste eerste indeling leidt tot langere oplostijden door her toewijzingen. Door incidenten per categorie te groeperen, kunnen organisaties terugkerende problemen herkennen, zien waar de meeste supportcapaciteit naartoe gaat en verbeterinitiatieven daarop afstemmen. Waarom dit belangrijk is Dit maakt analyse van incidenttrends mogelijk en helpt bepalen of een onjuiste categorisering vertraging bij de oplossing veroorzaakt. Waar je het vindt Dit is een standaard maar aanpasbaar veld in Freshservice. Het is beschikbaar in de Tickets API als 'category', met de gerelateerde velden 'sub_category' en 'item_category'. Voorbeelden HardwareSoftwareNetwerkprobleemToegang tot account
	Incidenternst IncidentSeverity	Het ernstniveau van het incident, dat de impact op de bedrijfsvoering aangeeft.
Beschrijving Incidenternst meet de impact van een incident op de bedrijfsvoering en wordt vaak ingedeeld als Low, Medium, High of Critical. Ernst hangt samen met prioriteit, maar richt zich op impact, terwijl prioriteit de urgentie aangeeft. De combinatie van ernst en impact bepaalt vaak de uiteindelijke prioriteit. Analyse op basis van ernst laat zien hoe goed de organisatie omgaat met incidenten met grote gevolgen voor de bedrijfsvoering. In dashboards wordt dit gebruikt om oplostijden en SLA-prestaties uit te splitsen, zodat incidenten met de grootste impact gedurende hun hele levenscyclus de juiste aandacht en capaciteit krijgen. Waarom dit belangrijk is Dit meet de impact van een incident op de bedrijfsvoering, zodat je de analyse kunt richten op de problemen met de grootste gevolgen. Waar je het vindt Dit is een standaardveld in Freshservice, beschikbaar via de Tickets API als 'impact'. De waarden zijn numeriek. Voorbeelden LaagGemiddeldHoog
	Incidentprioriteit IncidentPriority	Het prioriteitsniveau van het incident, dat bepaalt hoe dringend de reactie en oplossing moeten zijn.
Beschrijving Incidentprioriteit is een belangrijk veld dat bepaalt hoe snel en met hoeveel aandacht een incident moet worden behandeld. De prioriteit wordt meestal aangegeven op een schaal zoals Low, Medium, High en Urgent en bepaalt vaak de SLA-doelen. In process mining is prioriteit een belangrijke dimensie voor filtering en analyse. Je kunt de oplossingsprocessen van incidenten met een hoge en een lage prioriteit vergelijken en controleren of kritieke problemen efficiënt worden afgehandeld. Dashboards splitsen metrieken zoals doorlooptijd en SLA-naleving vaak uit naar prioriteit, zodat supportmanagers gerichte verbeteracties kunnen nemen. Waarom dit belangrijk is Dit helpt om de analyse te richten op de meest kritieke incidenten en is belangrijk voor het beoordelen van SLA-prestaties en de inzet van capaciteit. Waar je het vindt Beschikbaar in de Freshservice Tickets API als het veld 'priority'. De waarden zijn numeriek, bijvoorbeeld 1 voor Low en 4 voor Urgent. Voorbeelden LaagGemiddeldHoogUrgent
	Incidentstatus IncidentStatus	De huidige status van het incident in zijn levenscyclus, zoals Open, Pending, Resolved of Closed.
Beschrijving De Incidentstatus geeft de huidige toestand van het incident aan. Statuswijzigingen zijn belangrijke gebeurtenissen waarop de ontdekte procesmap is gebaseerd, zoals de overgang van 'In Progress' naar 'Pending' of van 'Resolved' naar 'Closed'. Dit attribuut is belangrijk om het verloop van het incident te begrijpen. Door de tijd in elke status te analyseren, kun je bottlenecks vinden, bijvoorbeeld incidenten die te lang de status 'Pending' hebben omdat ze op een reactie van de gebruiker wachten. Het attribuut is ook belangrijk voor het bepalen van de begin- en eindpunten bij het berekenen van doorlooptijden. Waarom dit belangrijk is Dit volgt de voortgang van het incident door zijn levenscyclus en helpt fasen te vinden waarin vaak vertraging ontstaat. Waar je het vindt Beschikbaar in de Freshservice Tickets API als het veld 'status'. De waarden zijn numeriek. Voorbeelden OpenIn behandelingIn afwachtingOpgelostGesloten
	Toegewezen agent AssignedAgent	De naam of ID van de supportagent die momenteel verantwoordelijk is voor het oplossen van het incident.
Beschrijving De Toegewezen agent identificeert de medewerker van de servicedesk die op een bepaald moment verantwoordelijk is voor het incident. Wijzigingen in dit attribuut staan voor een overdracht van eigenaarschap tussen agents. Dit attribuut is belangrijk voor prestatieanalyses. Je kunt er dashboards mee maken die de werklast van agents, de gemiddelde oplostijd per agent en het percentage first-contactoplossingen volgen. Je gebruikt het ook om overdrachten tussen agents te analyseren, omdat die vertraging en inefficiëntie kunnen veroorzaken. Door agenttoewijzingen te volgen, kunnen managers opleidingsbehoeften vaststellen en goed presterende teamleden herkennen. Waarom dit belangrijk is Dit maakt analyse mogelijk van agentprestaties, de verdeling van de werklast en het effect van agentoverdrachten op oplostijden. Waar je het vindt Beschikbaar in de Freshservice Tickets API als het veld 'responder_id'. Je kunt deze ID koppelen aan de Agents API om de naam van de agent op te halen. Voorbeelden John DoeJane SmithSupportBot
	Toegewezen groep AssignedGroup	De supportgroep of het team dat momenteel aan het incident is toegewezen.
Beschrijving De Toegewezen groep geeft aan welk team, zoals 'Level 1 Support', 'Network Team' of 'Database Admins', verantwoordelijk is voor het incident. Wijzigingen in dit attribuut wijzen op een escalatie of overdracht tussen verschillende functionele teams. Door de Toegewezen groep te analyseren, krijg je inzicht in vertragingen bij overdrachten. Process mining kan de flow van incidenten tussen groepen visualiseren, veelvoorkomende escalatieroutes zichtbaar maken en meten hoe lang incidenten wachten voordat elke groep actie onderneemt. Zo kun je organisatorische bottlenecks en mogelijkheden voor betere samenwerking tussen teams vinden. Waarom dit belangrijk is Dit houdt bij welk team verantwoordelijk is en is belangrijk voor het analyseren van overdrachten, escalaties en vertragingen tussen teams. Waar je het vindt Beschikbaar in de Freshservice Tickets API als het veld 'group_id'. Je kunt deze ID koppelen aan de Groups API om de naam van de groep op te halen. Voorbeelden ServicedeskNetwerkbeheerInfrastructuurondersteuning
	Aantal overdrachten HandoffCount	Het aantal keer dat een incident tussen verschillende agents of groepen is overgedragen.
Beschrijving Aantal overdrachten is een berekende metriek die het aantal her toewijzingen tijdens de levenscyclus van een incident meet. Elke wijziging in het attribuut 'AssignedAgent' of 'AssignedGroup' verhoogt deze teller. Een hoog aantal overdrachten wijst vaak op inefficiëntie in het proces, een onjuiste eerste routering of onvoldoende kennis bij agents. Deze metriek ondersteunt rechtstreeks de KPI 'Incident Handoff Count' en het dashboard 'Handoff And Transfer Delay Analysis'. Zo kun je incidenten of procesroutes met te veel overdrachten vinden, omdat die tot vertraging leiden. Waarom dit belangrijk is Dit meet herwerk en her toewijzingen en helpt inefficiëntie door onjuiste routering of kennishiaten te vinden. Waar je het vindt Dit is een berekende metriek die wordt afgeleid door het aantal verschillende waarden of wijzigingen in de velden 'AssignedAgent' of 'AssignedGroup' gedurende de levenscyclus van één incident te tellen. Voorbeelden 0125
	Afdeling van melder RequestersDepartment	De afdeling waartoe de gebruiker behoort die het incident heeft gemeld.
Beschrijving Dit attribuut identificeert de bedrijfsafdeling van de melder, zoals 'Sales', 'Finance' of 'IT'. Deze informatie komt meestal uit het gebruikersprofiel in Freshservice. Door incidenten te analyseren per afdeling van de melder, kun je zien of bepaalde bedrijfsonderdelen onevenredig vaak door problemen worden geraakt of dat er afdelingsspecifieke problemen zijn. Dit geeft waardevolle context voor de bedrijfsimpact van incidenten en helpt bij het prioriteren van oplossingen voor kritieke afdelingen. Waarom dit belangrijk is Dit geeft bedrijfscontext, zodat je incidenttrends en de impact op specifieke afdelingen kunt analyseren. Waar je het vindt Deze informatie is gekoppeld aan de melder van het ticket. Je kunt de informatie ophalen via het API-eindpunt 'Requesters' met de 'requester_id' uit het ticket en vervolgens de 'department_id' en naam opvragen. Voorbeelden SalesMarketingFinanciënHuman resources
	Hoofdoorzaak RootCause	De onderliggende reden of hoofdoorzaak die na onderzoek voor het incident is vastgesteld.
Beschrijving Het attribuut Hoofdoorzaak legt het onderliggende probleem vast dat tot het incident heeft geleid. Supportagents vullen deze informatie meestal tijdens of na de oplossing in als onderdeel van een root-causeanalyse (RCA). Dit attribuut is belangrijk voor het dashboard 'Recurring Incidents And Root Causes' en de KPI 'Root Cause Analysis Completion Rate'. Door veelvoorkomende hoofdoorzaken te analyseren, kunnen organisaties overstappen van reactief incidentherstel naar proactief probleembeheer. Zo kunnen ze permanente oplossingen invoeren die toekomstige incidenten voorkomen en terugkerende problemen verminderen. Waarom dit belangrijk is Dit ondersteunt proactief probleembeheer door de onderliggende oorzaken van terugkerende incidenten zichtbaar te maken en te helpen wegnemen. Waar je het vindt Dit is vaak een aangepast veld in Freshservice, omdat de standaardfunctionaliteit beperkt kan zijn. Controleer de configuratie van 'Ticket Fields' op een veld met de naam 'Root Cause' of een vergelijkbare naam. Voorbeelden SoftwarebugFout in netwerkconfiguratieProbleem met gebruikerstrainingHardwarestoring
	Is heropend IsReopened	Een berekende indicator die waar is als een incident na de status Resolved of Closed opnieuw is geopend.
Beschrijving Dit booleaanse attribuut is een berekende indicator voor incidenten die opnieuw zijn geopend. De waarde wordt waar als de status van een incident na de status 'Resolved' of 'Closed' teruggaat naar een open status of 'In Progress'. Deze indicator is belangrijk voor het berekenen van de KPI 'Incident Reopening Rate' en voor het dashboard 'Recurring Incidents'. Een hoog percentage heropende incidenten kan wijzen op problemen met de kwaliteit van de eerste oplossing, een onvolledige analyse van de hoofdoorzaak of een te vroege sluiting. Door deze cases te analyseren, kun je de kwaliteit en duurzaamheid van oplossingen verbeteren. Waarom dit belangrijk is Dit identificeert tekortkomingen in het oplossingsproces en laat incidenten zien waarbij de eerste oplossing niet werkte en herwerk nodig was. Waar je het vindt Dit is een berekend veld dat wordt afgeleid uit de volgorde van activiteiten in het event log. De waarde is waar als bijvoorbeeld de activiteit 'Incident Reopened' voorkomt of als voor dezelfde Incident-ID een activiteit met een open status volgt op een activiteit met een gesloten status. Voorbeelden truefalse
	Is SLA overschreden IsSlaBreached	Een berekende indicator die waar is als het incident niet binnen de vastgestelde SLA-doeltijd is opgelost.
Beschrijving Dit booleaanse attribuut is een berekende metriek die aangeeft of de oplostijd van een incident de SLA-doeltijd heeft overschreden. De waarde wordt afgeleid door de werkelijke timestamp van de oplossing te vergelijken met 'ResolutionSlaTargetTime'. Deze indicator is een directe invoer voor de KPI 'SLA Adherence Rate' en het dashboard 'SLA Performance Dashboard'. De analyse wordt eenvoudiger doordat elk incident een duidelijke binaire uitkomst voor de SLA-prestatie krijgt. Zo kun je aantallen en trends makkelijk samenvoegen en snel zien hoeveel incidenten niet aan de serviceafspraken voldoen. Waarom dit belangrijk is Dit meet de SLA-naleving per incident rechtstreeks, zodat je eenvoudig het totale nalevingspercentage kunt berekenen en probleemgebieden kunt vinden. Waar je het vindt Dit is een berekend veld dat tijdens de datatransformatie wordt afgeleid door de timestamp van 'Incident Resolved' te vergelijken met het veld 'ResolutionSlaTargetTime'. Voorbeelden truefalse
	Meldingskanaal ReportingChannel	De methode of het kanaal waarmee het incident is gemeld, zoals E-mail, Portal of Telefoon.
Beschrijving Het Meldingskanaal, ook wel de bron genoemd, identificeert hoe een incident het supportsysteem binnenkwam. Veelgebruikte kanalen zijn e-mail, een self-serviceportal, telefoongesprekken en chat. Door dit attribuut te analyseren, kun je de efficiëntie van verschillende meldingskanalen beoordelen. Het dashboard 'Reporting Channel Efficiency' vergelijkt het aantal incidenten en de gemiddelde oplostijd per kanaal. Zo zie je welke methoden het beste werken en waar procesverbetering nodig is. Incidenten die via het portal worden gemeld, kunnen bijvoorbeeld sneller worden opgelost als ze vanaf het begin meer gestructureerde informatie bevatten. Waarom dit belangrijk is Dit helpt de efficiëntste meldingskanalen te vinden en laat zien waar het proces voor het registreren van incidenten kan worden verbeterd. Waar je het vindt Beschikbaar in de Freshservice Tickets API als het veld 'source'. De waarden zijn numeriek. Voorbeelden E-mailPortaalTelefoonChat
	Workaround verstrekt WorkaroundProvided	Een indicator die aangeeft of de gebruiker vóór de definitieve oplossing een tijdelijke workaround heeft gekregen.
Beschrijving Dit booleaanse attribuut geeft aan of een tijdelijke oplossing of workaround is geïmplementeerd om de impact van het incident te beperken terwijl aan een permanente oplossing werd gewerkt. Dit wordt vaak bijgehouden met een selectievakje of een specifieke status. In process mining ondersteunt dit attribuut het dashboard 'Workaround Effectiveness Metrics'. Je kunt de oplostijden van incidenten met en zonder workaround vergelijken. Zo bepaal je of tijdelijke oplossingen de verstoring van de bedrijfsvoering effectief beperken en vanuit het perspectief van de gebruiker bijdragen aan een snellere totale oplossing. Waarom dit belangrijk is Dit helpt de effectiviteit van tijdelijke workarounds te meten bij het beperken van de impact van incidenten en het versnellen van de ervaren oplossing. Waar je het vindt Dit is meestal een aangepast booleaans veld (selectievakje). Je moet controleren of het bestaat in de configuratie van 'Ticket Fields' in Freshservice. Voorbeelden truefalse

Verplicht Aanbevolen Optioneel

Incidentbeheeractiviteiten

Dit zijn de belangrijkste processtappen en mijlpalen die je in je event log moet vastleggen voor een nauwkeurige procesontdekking en identificatie van bottlenecks.

7 Aanbevolen 7 Optioneel

	Activiteit	Beschrijving
	Incident gemeld	Dit markeert het aanmaken van een nieuw incidentrecord in Freshservice. Het is het startpunt van de levenscyclus van een incident. Meestal meldt een eindgebruiker het incident via een portal of e-mail, of maakt een servicedeskagent namens de gebruiker een ticket aan. Deze gebeurtenis wordt expliciet vastgelegd met een aanmaaktimestamp.
Waarom dit belangrijk is Deze activiteit is de primaire startgebeurtenis van het hele proces. De tijd tussen deze gebeurtenis en de oplossing analyseren is de basis voor het meten van totale doorlooptijden en SLA-naleving. Waar je het vindt Vastgelegd via de aanmaaktimestamp in de incidenttabel. Freshservice registreert deze timestamp expliciet voor elk nieuw ticket. Vastleggen Gebruik de timestamp 'Created at' uit het hoofdrecord van het incident. Eventtype explicit
	Incident gesloten	Dit staat voor de definitieve, formele sluiting van het incidentrecord. Dit gebeurt meestal automatisch nadat het incident een bepaalde tijd de status 'Resolved' heeft gehad, maar kan ook handmatig door een agent worden uitgevoerd. Deze gebeurtenis markeert het einde van de levenscyclus van het incident.
Waarom dit belangrijk is Deze activiteit is het definitieve eindpunt van het proces. De totale tijd tot deze gebeurtenis staat voor de volledige duur van de levenscyclus van het incident, inclusief eventuele perioden waarin op bevestiging van de gebruiker wordt gewacht. Waar je het vindt Afgeleid uit het activity log van het incident door vast te stellen wanneer het veld 'Status' wordt bijgewerkt naar 'Closed'. Vastleggen Gebruik de timestamp uit de activity-logvermelding voor de statuswijziging naar 'Closed'. Eventtype inferred
	Incident opgelost	Dit markeert het moment waarop de agent een oplossing heeft geïmplementeerd en het incident als opgelost beschouwt. Je legt dit vast wanneer de status van het incident wordt gewijzigd naar 'Resolved'. In Freshservice is dit een belangrijke mijlpaal die de SLA-klok stopt.
Waarom dit belangrijk is Dit is een belangrijke mijlpaal voor het meten van Time to Resolution (TTR). De periode tussen 'Resolved' en 'Closed' is relevant voor het analyseren van vertragingen bij gebruikersbevestiging en beleid voor automatisch sluiten. Waar je het vindt Afgeleid uit het activiteitenlog van het incident door vast te stellen wanneer het veld 'Status' wordt bijgewerkt naar 'Resolved'. Vastleggen Gebruik de timestamp uit de regel in het activiteitenlog voor de statuswijziging naar 'Resolved'. Eventtype inferred
	Incident toegewezen aan groep	Dit staat voor de eerste toewijzing van een incident aan een supportgroep. Dat kan automatisch via routeringsregels of handmatig door een dispatcher gebeuren. Je legt deze activiteit vast door de eerste invulling van het veld 'Group' in het auditlog van het incident te volgen.
Waarom dit belangrijk is Het volgen van toewijzingen is belangrijk om de eerste reactietijd te meten en bottlenecks in het dispatchproces te vinden. Zo kun je analyseren hoe efficiënt incidenten bij het juiste team terechtkomen. Waar je het vindt Afgeleid uit de eerste regel in het activiteitenlog van het incident waarin het veld 'Group' wordt ingevuld of gewijzigd. Vastleggen Bepaal de eerste timestamp waarop het veld 'Group' voor een incident wordt ingevuld. Eventtype inferred
	Oplossingsnotitie toegevoegd	Dit gebeurt wanneer een agent de oplossing van het incident documenteert door een oplossingsnotitie toe te voegen. In Freshservice is dit een afzonderlijke actie voordat de status wordt gewijzigd naar 'Resolved'. De actie en de inhoud ervan worden expliciet geregistreerd.
Waarom dit belangrijk is Dit markeert het vaststellen van een oplossing. De tijd tussen deze activiteit en de status 'Incident Resolved' kan wijzen op interne controle of extra tijd voor documentatie. Waar je het vindt Vastgelegd via de timestamp waarop een oplossingsnotitie aan het incident wordt toegevoegd. Deze wordt geregistreerd in de gespreksgeschiedenis. Vastleggen Identificeer de timestamp van de regel 'Resolution Note' in het gesprekslog van het incident. Eventtype explicit
	Prioriteit van incident ingesteld	Dit gebeurt wanneer de prioriteit van het incident wordt ingesteld of bijgewerkt. Het prioriteitsniveau bepaalt de urgentie en de SLA-doelen voor de oplossing. Je legt dit vast door wijzigingen in het veld 'Priority' in de geschiedenis van het incident te volgen.
Waarom dit belangrijk is Een onjuiste of vertraagde prioritering kan leiden tot SLA-overschrijdingen en een inefficiënte inzet van bronnen. Door deze activiteit te analyseren, zorg je ervoor dat kritieke incidenten meteen aandacht krijgen. Waar je het vindt Afgeleid uit het activiteitenlog van het incident, waarin alle updates van het veld 'Priority' worden bijgehouden. Vastleggen Gebruik timestamps uit het auditlog waarop de waarde van het veld 'Priority' is ingesteld of gewijzigd. Eventtype inferred
	Status gewijzigd naar In Progress	Deze activiteit markeert de officiële start van het actieve onderzoek en werk aan het incident. Je legt dit vast wanneer een agent de status van het incident wijzigt naar 'In Progress'. Dit is een standaardstatuswijziging die in de activiteitengeschiedenis van het ticket wordt geregistreerd.
Waarom dit belangrijk is Deze mijlpaal helpt wachttijd te onderscheiden van actieve werktijd. De duur analyseren waarin een incident de status 'In Progress' heeft, is belangrijk om de benodigde inspanning voor de oplossing te begrijpen. Waar je het vindt Afgeleid uit het activiteitenlog van het incident door vast te stellen wanneer het veld 'Status' wordt bijgewerkt naar 'In Progress'. Vastleggen Filter het activiteitenlog op een statuswijziging naar 'In Progress' en gebruik de bijbehorende timestamp. Eventtype inferred
	Agent toegewezen aan incident	Deze activiteit markeert het moment waarop een specifieke agent het incident toegewezen krijgt. Daarmee wordt duidelijk wie eigenaar is van het ticket. De toewijzing wordt vastgelegd in de activiteitengeschiedenis van het ticket, inclusief de toegewezen agent en het tijdstip.
Waarom dit belangrijk is Hiermee kun je de werkbelasting en prestaties van agents analyseren, evenals de tijd tussen de toewijzing aan een groep en het oppakken van het incident door een individuele agent. Dit is belangrijk voor dashboards over agentprestaties. Waar je het vindt Gevolgd via wijzigingen in het veld 'Agent' in het activiteitenlog of audittrail van het incident. Vastleggen Identificeer timestamps die overeenkomen met wijzigingen in het veld 'Agent'. Eventtype inferred
	Eerste reactie verzonden	Deze activiteit staat voor de eerste communicatie van een agent naar de gebruiker nadat het incident is gemeld. Dat kan een openbare notitie of een rechtstreeks antwoord zijn. Freshservice registreert alle communicatie van agents met timestamps.
Waarom dit belangrijk is Het halen van de SLA voor de eerste reactie is een belangrijke KPI voor klanttevredenheid. Met deze activiteit kun je meten en analyseren hoe snel agents nieuwe incidenten oppakken. Waar je het vindt Vastgesteld door de timestamp te vinden van de eerste openbare notitie of reactie die een agent toevoegt aan het gesprekslog van het incident. Vastleggen Filter de gespreksgeschiedenis van het incident op de vroegste regel die door een agent is toegevoegd. Eventtype explicit
	Incident heropend	Dit gebeurt wanneer een incident dat eerder als 'Resolved' is gemarkeerd, teruggaat naar een open status. Meestal komt dat doordat de gebruiker het niet eens is met de oplossing. Je leidt dit af uit een statuswijziging van 'Resolved' terug naar bijvoorbeeld 'Open' of 'In Progress'.
Waarom dit belangrijk is Een hoog percentage heropeningen wijst op problemen met de kwaliteit van oplossingen of op onvolledig herstel. Dit is een belangrijke maatstaf voor het analyseren van herstelwerk en agentprestaties. Waar je het vindt Afgeleid uit het activity log van het incident door een statuswijziging van 'Resolved' naar een actieve status te detecteren. Vastleggen Filter het activity log op een wijziging van 'Status' van 'Resolved' naar 'Open' of 'In Progress'. Eventtype inferred
	Incident opnieuw toegewezen	Dit geeft aan dat het incident van de ene agent of groep naar een andere is overgedragen. Het markeert een overdracht in het oplossingsproces. Je leidt deze gebeurtenis af uit latere wijzigingen in de velden 'Agent' of 'Group' na de eerste toewijzing.
Waarom dit belangrijk is Veelvuldige hernieuwde toewijzingen, of overdrachten, wijzen vaak op inefficiënte processen, kennishiaten of een onjuiste eerste routering. Door deze gebeurtenissen te analyseren, kun je vertragingen vinden en verminderen. Waar je het vindt Afgeleid uit het activiteitenlog van het incident door elke wijziging in de velden 'Agent' of 'Group' na de eerste toewijzing te volgen. Vastleggen Detecteer wijzigingen in de velden 'Agent' of 'Group' in de auditgeschiedenis van het ticket. Eventtype inferred
	SLA-doel overschreden	Dit is een berekende gebeurtenis die optreedt wanneer de verstreken tijd van een incident het vastgestelde SLA-doel voor reactie of oplossing overschrijdt. Freshservice houdt de SLA-status intern bij. Je kunt deze gebeurtenis afleiden door timestamps met SLA-beleid te vergelijken.
Waarom dit belangrijk is Hiermee meet je rechtstreeks of serviceafspraken worden nageleefd. Vaststellen wanneer en waarom overschrijdingen ontstaan is belangrijk voor het SLA Performance Dashboard en voortdurende verbetering. Waar je het vindt Berekend door de timestamp van de oplossing of reactie te vergelijken met de uiterste tijd volgens de SLA. Freshservice markeert tickets vaak als 'SLA Violated'. Vastleggen Leid dit af door de timestamp 'Resolved at' te vergelijken met 'Due by', of wanneer de waarde van het veld 'SLA Status' verandert naar 'Violated'. Eventtype calculated
	Status gewijzigd naar Pending	Dit markeert een moment waarop het oplossingsproces wordt gepauzeerd, meestal omdat informatie van de gebruiker of een derde partij nodig is. Je leidt dit af uit een statuswijziging naar een status 'Pending'. De tijd in deze status telt vaak niet mee voor SLA-berekeningen.
Waarom dit belangrijk is De tijd in statussen als 'Pending' identificeren is belangrijk om externe afhankelijkheden en vertragingen te begrijpen. Zo kun je werktijd van agents onderscheiden van wachttijd. Waar je het vindt Afgeleid uit het activiteitenlog van het incident wanneer het veld 'Status' wordt bijgewerkt naar bijvoorbeeld 'Pending' of 'Awaiting User Response'. Vastleggen Filter het activiteitenlog op statuswijzigingen naar een status 'Pending' en gebruik de bijbehorende timestamp. Eventtype inferred
	Workaround verstrekt	Deze activiteit betekent dat een tijdelijke oplossing of workaround met de gebruiker is gedeeld om de impact van het incident te beperken. Hiervoor is vaak een specifieke systeemconfiguratie nodig, zoals een apart selectievakje, een specifiek type notitie of een analyse van trefwoorden in notities van agents.
Waarom dit belangrijk is Hiermee kun je de effectiviteit van workarounds bij het beperken van de impact op de bedrijfsvoering analyseren en de relatie met de uiteindelijke oplostijd onderzoeken. Dit ondersteunt het dashboard Workaround Effectiveness Metrics. Waar je het vindt Dit is waarschijnlijk geen expliciete gebeurtenis. Je kunt de gebeurtenis afleiden door notities met trefwoorden zoals 'workaround' te markeren, of wanneer een wijziging in een aangepast veld 'Workaround Provided' wordt geregistreerd. Vastleggen Afgeleid uit een wijziging in een aangepast veld of uit trefwoordanalyse van notities van agents. Eventtype inferred

Aanbevolen Optioneel

Extractiegidsen

Zo haal je je data uit Freshservice

Stappen

Freshservice Analyse openen: Meld je aan bij je Freshservice-instance met een account dat rechten heeft om rapporten te openen en te maken. Ga vanuit het hoofdmenu naar de module Analyse.
Een nieuw rapport maken: Klik op de knop Nieuw rapport. Geef het rapport een duidelijke naam, zoals "Incident Management Event Log". Selecteer de module Incidentbeheer wanneer je een databron moet kiezen.
Een rapportwidget selecteren: Voeg in de rapporteditor een nieuwe widget toe en selecteer het type Tabel. Dit vormt de basis van de data in je event log.
Primaire datakolommen toevoegen: Sleep vanuit het deelvenster met de databron aan de rechterkant de benodigde velden naar de kolomconfiguratie van de tabel. Begin met Incident ID, Created at, Agent, Group, Priority, Severity, Status en Category.
Activiteitsdata toevoegen: Om afzonderlijke events vast te leggen, moet je data uit de ticketactiviteiten koppelen of opnemen. Voeg de databron Activities aan je widget toe. Voeg vanuit deze bron Performed at toe voor de eventtimestamp en Activity description of vergelijkbare velden die de uitgevoerde wijziging beschrijven.
Een berekende kolom 'ActivityName' maken: Dit is de belangrijkste stap. Maak een nieuwe berekende kolom of formuleveld. Gebruik geneste IF-statements of een CASE-functie om ruwe activiteitsdata te vertalen naar de vereiste waarden voor ActivityName. Raadpleeg het querygedeelte voor de gedetailleerde logica van elk van de 14 activiteiten.
'EventTimestamp' configureren: Maak nog een berekende kolom voor EventTimestamp. Deze kolom moet voor de activiteit 'Incident Reported' de timestamp van Created at gebruiken en voor alle andere events de timestamp van Performed at.
Rapportfilters toepassen: Configureer de rapportfilters om de data af te bakenen. Stel minimaal een datumbereikfilter in op het veld 'Created at'. Een periode van de afgelopen 3 tot 6 maanden wordt aanbevolen. Voeg ook een filter toe om alleen tickets op te nemen waarvan 'Ticket Type' gelijk is aan 'Incident'.
Het rapport uitvoeren en verfijnen: Voer het rapport uit om een preview van de data te genereren. Controleer of de kolommen ActivityName en EventTimestamp correct worden gevuld. Pas formules en filters zo nodig aan.
Het rapport opslaan en exporteren: Sla het rapport op zodra je tevreden bent met de uitvoer. Gebruik de optie Exporteren en selecteer CSV als indeling.
De export plannen (optioneel): Voor doorlopende analyse kun je het rapport automatisch laten uitvoeren en exporteren. Stel een schema in, bijvoorbeeld dagelijks of wekelijks, zodat het CSV-bestand naar je e-mail of een andere bestemming wordt gestuurd.
Data voorbereiden voor upload: Open het geëxporteerde CSV-bestand. Hernoem de kolomkoppen zodat ze overeenkomen met het vereiste schema van ProcessMind: IncidentId, ActivityName, EventTimestamp, AssignedAgent, AssignedGroup enzovoort. Voeg de vaste kolommen SourceSystem met de waarde 'Freshservice' en LastDataUpdate met de huidige timestamp toe. Het bestand is nu klaar om te worden geüpload.

Configuratie

Analytics-module: Voor deze extractie heb je toegang nodig tot de Freshservice Analytics-module. Deze is beschikbaar in uitgebreidere abonnementen, zoals Pro en Enterprise.
Vereiste rechten: Je gebruikersaccount moet een rol hebben waarmee je rapporten in de Analytics-module kunt maken, bewerken en uitvoeren.
Datumbereik: Stel een datumfilter in op de aanmaakdatum van incidenten om de hoeveelheid data beheersbaar te houden. Een doorlopende periode van 3 tot 6 maanden is aan te raden voor een goede balans tussen historische context en prestaties.
Rapportfilters: Filter altijd op Ticket Type = Incident, zodat serviceaanvragen en andere tickettypen buiten je procesanalyse blijven.
Berekende velden: Deze methode gebruikt veel berekende velden, zoals formules, om ActivityName en EventTimestamp voor elke gebeurtenis af te leiden. Kennis van de Freshservice-formule-editor is handig.
Datavolume: Houd er rekening mee dat deze extractie voor elk incident meerdere rijen oplevert, één per activiteit. Bij grote Freshservice-instanties kan het CSV-bestand daardoor erg groot worden. Dat heeft invloed op de rapportgeneratie en exportsnelheid.

a Voorbeeldquery config

// This is a conceptual configuration for the Freshservice Analytics report builder, not an executable script.
// The logic should be implemented using the UI's formula fields and widget settings.

REPORT_WIDGET_TYPE: Table

DATA_SOURCES:
  - Primary: Incidents
  - Additional: Ticket Activities

COLUMNS_AND_DERIVATION_LOGIC:

1.  **IncidentId**
    - Source: Incidents."ID"

2.  **ActivityName** (Calculated Column using a Formula)
    - This formula combines multiple IF conditions to generate the activity name based on the activity type and data changes. The logic below represents a CASE statement structure.
    - **WHEN** Activity Type is 'Created': 'Incident Reported'
    - **WHEN** Activity Field is 'Group' and it is the first update to this field for the ticket: 'Incident Assigned to Group'
    - **WHEN** Activity Field is 'Agent' and it is the first update to this field for the ticket: 'Agent Assigned to Incident'
    - **WHEN** Activity Field is 'Priority': 'Incident Prioritized'
    - **WHEN** Activity Type is 'First Response Sent': 'First Response Sent'
    - **WHEN** Activity Field is 'Group' and it is NOT the first update: 'Incident Reassigned'
    - **WHEN** Activity Field is 'Agent' and it is NOT the first update: 'Incident Reassigned'
    - **WHEN** Activity Field is 'Status' and New Value is 'In Progress': 'Status Changed to In Progress'
    - **WHEN** Activity Field is 'Status' and New Value is 'Pending': 'Status Changed to Pending'
    - **WHEN** Activity Note contains 'Workaround Provided' or a specific workaround tag is added: 'Workaround Provided'
    - **WHEN** Activity Type is 'Resolution Note Added': 'Resolution Note Added'
    - **WHEN** Activity Field is 'Status' and New Value is 'Resolved': 'Incident Resolved'
    - **WHEN** Activity Type is 'SLA Violated' and SLA Type is 'Resolution': 'SLA Target Breached'
    - **WHEN** Activity Field is 'Status' and Old Value was 'Resolved' and New Value is 'Open': 'Incident Reopened'
    - **WHEN** Activity Field is 'Status' and New Value is 'Closed': 'Incident Closed'

3.  **EventTimestamp** (Calculated Column using a Formula)
    - **IF** ActivityName is 'Incident Reported', THEN use Incidents."Created at"
    - **ELSE**, use Ticket Activities."Performed at"

4.  **SourceSystem** (Calculated Column)
    - Value: 'Freshservice'

5.  **LastDataUpdate** (Calculated Column)
    - Value: Use a formula function that returns the current timestamp of the report execution.

6.  **AssignedAgent**
    - Source: Ticket Activities."Performed By" if available, otherwise the current Incidents."Agent"

7.  **AssignedGroup**
    - Source: The value of the 'Group' field at the time of the activity.

8.  **IncidentPriority**
    - Source: The value of the 'Priority' field at the time of the activity.

9.  **IncidentSeverity**
    - Source: The value of the 'Severity' field at the time of the activity.

10. **IncidentStatus**
    - Source: The new value from the 'Status' field change activity.

11. **IncidentCategory**
    - Source: The value of the 'Category' field at the time of the activity.

12. **ResolutionSlaTargetTime**
    - Source: Incidents."Resolution due by"

REPORT_FILTERS:
  - Incidents."Created at" BETWEEN '[Specify Start Date]' AND '[Specify End Date]'
  - Incidents."Type" EQUALS 'Incident'

Stappen

Vereisten: Installeer Python 3.6 of hoger en de bibliotheken requests en pandas. Je kunt deze installeren met pip: pip install requests pandas.
Genereer een API-sleutel: Log als beheerder in op je Freshservice-instantie. Open Profile Settings via je profielfoto rechtsboven. Ga naar het gedeelte 'API Key' en kopieer je persoonlijke API-sleutel. Behandel deze sleutel als een wachtwoord.
Stel het script in: Sla de aangeleverde Python-code op je computer op in een bestand met de naam extract_freshservice_incidents.py.
Configureer de parameters: Open het script in een teksteditor. Werk de tijdelijke waarden bij voor FRESHSERVICE_DOMAIN, bijvoorbeeld 'yourcompany.freshservice.com', API_KEY, de sleutel die je net hebt gekopieerd, en START_DATE_STR, het begin van de gewenste extractieperiode in de notatie 'YYYY-MM-DD'.
Begrijp de logica van het script: Het script haalt eerst alle incidenttickets op die na de opgegeven startdatum zijn aangemaakt. Daarna doorloopt het elke resultatenpagina van de API. Voor elk ticket doet het een tweede API-aanroep om de gedetailleerde activiteitengeschiedenis op te halen.
Genereren van het event log: Het script verwerkt de kerndata van het ticket en het activiteitenlogboek om records te maken voor elk van de 14 vereiste bedrijfsactiviteiten. Zo wordt Incident Reported gebaseerd op de aanmaakdatum van het ticket en Status Changed to In Progress afgeleid uit een specifieke vermelding in het activiteitenlogboek.
Leid complexe gebeurtenissen af: Gebeurtenissen zoals SLA Target Breached worden afgeleid. Het script controleert of de resolution SLA van een ticket is overschreden. Zo ja, dan maakt het een gebeurtenis met de due_by-datum als timestamp, die het moment van de overschrijding markeert.
Voer het script uit: Open een terminal of opdrachtprompt, ga naar de map waarin je het script hebt opgeslagen en voer het uit met de opdracht: python extract_freshservice_incidents.py.
Volg de uitvoering: Het script toont voortgang in de console, inclusief het aantal verwerkte tickets. Afhankelijk van het aantal tickets en de API-limieten kan dit even duren.
Controleer de uitvoer: Na afloop maakt het script in dezelfde map een CSV-bestand met de naam freshservice_incident_event_log.csv. Dit bestand bevat het volledige event log.
Bereid de upload voor: Open het CSV-bestand in een spreadsheetprogramma en controleer of de kolommen, zoals IncidentId, ActivityName en EventTimestamp, goed zijn gevuld. Het bestand is nu klaar om te uploaden naar ProcessMind of een andere process mining-tool.

Configuratie

FRESHSERVICE_DOMAIN: De specifieke Freshservice-URL van je bedrijf, bijvoorbeeld mycompany.freshservice.com. Dit is een verplichte parameter in het script.
API_KEY: De persoonlijke API-sleutel van een gebruiker met voldoende rechten om alle incidentdata te lezen. Dit is een verplichte parameter.
START_DATE_STR: De startdatum van de data-extractie in de notatie 'YYYY-MM-DD'. Voor een zinvolle analyse raden we aan om eerst 3 tot 6 maanden aan data te extraheren.
PAGE_SIZE: Stel dit in op 100, het maximum dat de Freshservice API toestaat. Zo beperk je het aantal API-aanroepen en verbeter je de prestaties. Het is meestal niet aan te raden deze waarde te wijzigen.
API Rate Limiting: Het script bevat een eenvoudige time.sleep(1)-aanroep na de verwerking van elk ticket om de API-limieten van Freshservice te respecteren. Bij instanties met veel data moet je dit mogelijk aanpassen om fouten te voorkomen.
Vereiste rechten: De API-sleutel moet horen bij een gebruikersaccount, bijvoorbeeld een speciaal serviceaccount, met minimaal de rechten van de rol 'SD Agent'. Zo krijgt het script toegang tot alle benodigde ticketvelden en activiteitenlogboeken binnen verschillende servicedesk-groepen.

a Voorbeeldquery python

import requests
import pandas as pd
import time
import datetime
import os

class=class="hl-string">"hl-comment"># --- Configuration Settings ---
class=class="hl-string">"hl-comment"># Replace with your Freshservice domain
FRESHSERVICE_DOMAIN = class="hl-string">"[your_domain].freshservice.com"
class=class="hl-string">"hl-comment"># Replace with your Freshservice API Key
API_KEY = class="hl-string">"[your_api_key]"
class=class="hl-string">"hl-comment"># Set the start date for the extraction (YYYY-MM-DD)
START_DATE_STR = class="hl-string">"2023-01-01"

class=class="hl-string">"hl-comment"># --- Constants ---
BASE_URL = fclass="hl-string">"https протокол://{FRESHSERVICE_DOMAIN}/api/v2"
PAGE_SIZE = 100
OUTPUT_FILENAME = class="hl-string">"freshservice_incident_event_log.csv"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def create_event(incident_id, activity_name, event_timestamp, ticket_data, source_system, last_data_update):
    class="hl-string">"""Helper function to create a structured event dictionary."""
    class=class="hl-string">"hl-comment"># Use latest known values for attributes if available
    sla_policy = ticket_data.get(class="hl-string">'sla_policy', {})
    resolution_due = None
    if sla_policy and sla_policy.get(class="hl-string">'resolution_sla', {}):
        resolution_due = sla_policy.get(class="hl-string">'resolution_sla', {}).get(class="hl-string">'due_by')

    return {
        class="hl-string">"IncidentId": incident_id,
        class="hl-string">"ActivityName": activity_name,
        class="hl-string">"EventTimestamp": event_timestamp,
        class="hl-string">"SourceSystem": source_system,
        class="hl-string">"LastDataUpdate": last_data_update,
        class="hl-string">"AssignedAgent": ticket_data.get(class="hl-string">'responder_id'),
        class="hl-string">"AssignedGroup": ticket_data.get(class="hl-string">'group_id'),
        class="hl-string">"IncidentPriority": ticket_data.get(class="hl-string">'priority'),
        class="hl-string">"IncidentSeverity": ticket_data.get(class="hl-string">'impact'), class=class="hl-string">"hl-comment"># Impact is often used for Severity
        class="hl-string">"IncidentStatus": ticket_data.get(class="hl-string">'status'),
        class="hl-string">"IncidentCategory": ticket_data.get(class="hl-string">'category'),
        class="hl-string">"ResolutionSlaTargetTime": resolution_due
    }

def get_all_tickets(session, start_date):
    class="hl-string">"""Fetches all tickets from Freshservice updated since the start date, handling pagination."""
    tickets = []
    page = 1
    while True:
        params = {
            class="hl-string">"updated_since": start_date + class="hl-string">"T00:00:00Z",
            class="hl-string">"per_page": PAGE_SIZE,
            class="hl-string">"page": page,
            class="hl-string">"order_type": class="hl-string">"asc" class=class="hl-string">"hl-comment"># Process tickets in chronological order
        }
        try:
            response = session.get(fclass="hl-string">"{BASE_URL}/tickets", params=params)
            response.raise_for_status()
            data = response.json().get(class="hl-string">"tickets", [])
            if not data:
                break
            tickets.extend(data)
            print(fclass="hl-string">"Fetched page {page}, {len(data)} tickets...")
            page += 1
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching tickets: {e}")
            break
    return tickets

def get_ticket_activities(session, ticket_id):
    class="hl-string">"""Fetches all activities (audit log) for a specific ticket."""
    try:
        response = session.get(fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/activities")
        response.raise_for_status()
        return response.json().get(class="hl-string">"activities", [])
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching activities for ticket {ticket_id}: {e}")
        return []

def main():
    class="hl-string">"""Main function to run the extraction process."""
    session = requests.Session()
    session.auth = (API_KEY, class="hl-string">'X') class=class="hl-string">"hl-comment"># class="hl-string">'X' is a placeholder password
    session.headers.update({class="hl-string">'Content-Type': class="hl-string">'application/json'})

    last_data_update = datetime.datetime.now(datetime.timezone.utc).isoformat()
    source_system = class="hl-string">'Freshservice'
    event_log = []

    print(class="hl-string">"Starting Freshservice incident extraction...")
    all_tickets = get_all_tickets(session, START_DATE_STR)
    print(fclass="hl-string">"Total tickets to process: {len(all_tickets)}")

    for i, ticket in enumerate(all_tickets):
        incident_id = ticket[class="hl-string">'id']
        print(fclass="hl-string">"Processing ticket {i+1}/{len(all_tickets)}: ID {incident_id}")

        class=class="hl-string">"hl-comment"># 1. Incident Reported
        event_log.append(create_event(incident_id, class="hl-string">"Incident Reported", ticket[class="hl-string">'created_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># Fetch detailed activities for more events
        activities = get_ticket_activities(session, incident_id)
        
        assigned_group_done = False
        agent_assigned_done = False
        first_response_done = False

        for activity in sorted(activities, key=lambda x: x[class="hl-string">'performed_at']):
            activity_ts = activity[class="hl-string">'performed_at']
            class=class="hl-string">"hl-comment"># 2. Incident Assigned to Group (first occurrence)
            if not assigned_group_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'group_id' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Assigned to Group", activity_ts, ticket, source_system, last_data_update))
                assigned_group_done = True
            
            class=class="hl-string">"hl-comment"># 3. Agent Assigned to Incident (first occurrence)
            if not agent_assigned_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'responder_id' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Agent Assigned to Incident", activity_ts, ticket, source_system, last_data_update))
                agent_assigned_done = True

            class=class="hl-string">"hl-comment"># 4. Incident Prioritized
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'priority' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Prioritized", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># 5. First Response Sent (first public note by an agent)
            if not first_response_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and activity.get(class="hl-string">'note', {}).get(class="hl-string">'private') is False and activity.get(class="hl-string">'performer_type') == class="hl-string">'User':
                event_log.append(create_event(incident_id, class="hl-string">"First Response Sent", activity_ts, ticket, source_system, last_data_update))
                first_response_done = True

            class=class="hl-string">"hl-comment"># 6. Incident Reassigned (subsequent assignments)
            if (assigned_group_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'group_id' in activity.get(class="hl-string">'changes', {})) or \
               (agent_assigned_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'responder_id' in activity.get(class="hl-string">'changes', {})):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Reassigned", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># Status Changes
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'status' in activity.get(class="hl-string">'changes', {}):
                new_status = activity[class="hl-string">'changes'][class="hl-string">'status'][1]
                class=class="hl-string">"hl-comment"># 7. Status Changed to In Progress
                if new_status == 3: class=class="hl-string">"hl-comment"># Assuming 3 is class="hl-string">'In Progress'
                    event_log.append(create_event(incident_id, class="hl-string">"Status Changed to In Progress", activity_ts, ticket, source_system, last_data_update))
                class=class="hl-string">"hl-comment"># 8. Status Changed to Pending
                elif new_status == 6: class=class="hl-string">"hl-comment"># Assuming 6 is class="hl-string">'Pending'
                    event_log.append(create_event(incident_id, class="hl-string">"Status Changed to Pending", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># 9. Workaround Provided (Keyword search in notes)
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and class="hl-string">'workaround' in activity.get(class="hl-string">'note', {}).get(class="hl-string">'body_text', class="hl-string">'').lower():
                event_log.append(create_event(incident_id, class="hl-string">"Workaround Provided", activity_ts, ticket, source_system, last_data_update))
            
            class=class="hl-string">"hl-comment"># 10. Resolution Note Added
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and activity.get(class="hl-string">'note', {}).get(class="hl-string">'note_type') == class="hl-string">'resolution':
                event_log.append(create_event(incident_id, class="hl-string">"Resolution Note Added", activity_ts, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 11. Incident Resolved
        if ticket.get(class="hl-string">'resolved_at'):
            event_log.append(create_event(incident_id, class="hl-string">"Incident Resolved", ticket[class="hl-string">'resolved_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 12. SLA Target Breached
        if ticket.get(class="hl-string">'sla_policy') and ticket[class="hl-string">'sla_policy'].get(class="hl-string">'violation_details', {}).get(class="hl-string">'resolution_sla', {}).get(class="hl-string">'is_violated'):
            breach_time = ticket[class="hl-string">'sla_policy'][class="hl-string">'violation_details'][class="hl-string">'resolution_sla'][class="hl-string">'due_by']
            event_log.append(create_event(incident_id, class="hl-string">"SLA Target Breached", breach_time, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 13. Incident Reopened
        if ticket.get(class="hl-string">'reopened'):
            class=class="hl-string">"hl-comment"># Finding the exact reopened timestamp can be tricky, we approximate from class="hl-string">'stats'
            reopen_ts = ticket.get(class="hl-string">'stats', {}).get(class="hl-string">'reopened_at', ticket[class="hl-string">'updated_at'])
            event_log.append(create_event(incident_id, class="hl-string">"Incident Reopened", reopen_ts, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 14. Incident Closed
        if ticket.get(class="hl-string">'closed_at'):
            event_log.append(create_event(incident_id, class="hl-string">"Incident Closed", ticket[class="hl-string">'closed_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># Be respectful of API rate limits
        time.sleep(1)

    class=class="hl-string">"hl-comment"># Convert to DataFrame and save
    if event_log:
        df = pd.DataFrame(event_log)
        df[class="hl-string">'EventTimestamp'] = pd.to_datetime(df[class="hl-string">'EventTimestamp'])
        df = df.sort_values(by=[class="hl-string">'IncidentId', class="hl-string">'EventTimestamp'])
        df.to_csv(OUTPUT_FILENAME, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f%z')
        print(fclass="hl-string">"\nSuccessfully extracted {len(df)} events for {df['IncidentId'].nunique()} incidents.")
        print(fclass="hl-string">"Event log saved to {OUTPUT_FILENAME}")
    else:
        print(class="hl-string">"No events were generated.")

if __name__ == class="hl-string">"__main__":
    main()

Stappen

Controleer of je Freshservice-abonnement en beheerdersrechten Workflow Automator-regels, webhookacties, toegang tot incidenten en toegang tot de activiteitengeschiedenis van tickets toestaan. Stem het doelendpoint, de authenticatiemethode, TLS-vereisten en het bewaarbeleid af met het ontvangende team.
Leg het eventcontract vast voordat je de automator configureert. Gebruik één JSON-object per webhooklevering met IncidentId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, AssignedAgent, AssignedGroup, IncidentPriority, IncidentSeverity, IncidentStatus, IncidentCategory en ResolutionSlaTargetTime. Configureer de ontvanger zo dat de oorspronkelijke webhookpayload en de leveringstimestamp behouden blijven.
Maak een Workflow Automator-regel voor het aanmaken van incidenten. Laat de regel uitvoeren wanneer een incident wordt aangemaakt en voeg daarna een webhookactie toe die de activiteit Incident Reported verstuurt. Stel EventTimestamp in op de aanmaaktimestamp van het incident en ActivityName op Incident Reported.
Maak updateregels voor wijzigingen in toewijzing, prioriteit, status, communicatie, notities, SLA en afsluiting. Gebruik voorwaarden op basis van de incidentvelden en activiteitengeschiedenis die in je Freshservice-account beschikbaar zijn. Elke regel moet een afzonderlijke webhookgebeurtenis versturen wanneer de bijbehorende activiteit plaatsvindt. Laat ProcessMind activiteiten niet afleiden uit alleen een eindmomentopname van het incident.
Configureer expliciete activiteitsmapping. Verstuur Incident Assigned to Group wanneer het veld Group voor het eerst een waarde krijgt, Agent Assigned to Incident wanneer het veld Agent voor het eerst een waarde krijgt, Incident Prioritized wanneer Priority wordt ingesteld of gewijzigd, First Response Sent wanneer het eerste kwalificerende openbare antwoord of de eerste openbare notitie van een agent wordt vastgelegd, Incident Reassigned wanneer Agent of Group na de eerste toewijzing wijzigt, Status Changed to In Progress en Status Changed to Pending bij de bijbehorende statusovergangen, Workaround Provided alleen wanneer een geconfigureerde workaround-indicator aanwezig is, Resolution Note Added wanneer een oplossingsnotitie wordt toegevoegd, Incident Resolved wanneer de status verandert in Resolved, SLA Target Breached wanneer aan de geconfigureerde SLA-overschrijdingsvoorwaarde is voldaan, Incident Reopened wanneer de status verandert van Resolved naar een open status en Incident Closed wanneer de status verandert in Closed.
Configureer de body van het webhookverzoek als JSON. Neem de incidentidentifier, activiteitsnaam, eventtimestamp, het bronsysteem, de laatste data-update en de aanbevolen contextuele attributen op. Gebruik de Freshservice-webhookvariabelen die in jouw account beschikbaar zijn. Als een verplichte variabele niet beschikbaar is in de webhookeditor, vul je deze in de ontvangende service aan via een goedgekeurde Freshservice-interface. Laat de waarde anders leeg, in plaats van deze zelf te verzinnen.
Configureer idempotentie en afhandeling van leveringen op het endpoint. Gebruik een stabiele gebeurtenisidentifier als Freshservice die beschikbaar stelt. Maak anders een deduplicatiesleutel op basis van IncidentId, ActivityName, EventTimestamp en de identifier van de bronlevering. Geef pas een succesvolle HTTP-respons terug nadat de payload duurzaam is opgeslagen.
Test elke regel met gecontroleerde incidenten. Maak een incident aan, wijs een groep en agent toe, wijzig prioriteit en status, verstuur een kwalificerende reactie, voeg indien geconfigureerd een workaround en oplossingsnotitie toe, los het incident op, heropen het en sluit het. Test een SLA-overschrijding afzonderlijk met een gecontroleerd beleid of een testwachtrij. Controleer of elke verwachte activiteit als afzonderlijke webhookpayload binnenkomt.
Sla de webhookpayloads op in een duurzame stagingomgeving, normaliseer timestamps naar één tijdzone en zet elke payload om naar één rij in het event log. Behoud één rij per expliciete webhookactiviteit. Vul LastDataUpdate met de timestamp van de extractie of gegevensinname, niet met de timestamp van de bedrijfsgebeurtenis.
Valideer het gestagede event log, verwijder alleen exact dubbele leveringen en behoud legitieme herhaalde activiteiten, zoals meerdere prioriteitswijzigingen of statusovergangen. Controleer of IncidentId, ActivityName, EventTimestamp, SourceSystem en LastDataUpdate in elke rij aanwezig zijn.
Exporteer het genormaliseerde event log als CSV of een ander door ProcessMind ondersteund formaat. Gebruik exact de kolomnamen IncidentId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, AssignedAgent, AssignedGroup, IncidentPriority, IncidentSeverity, IncidentStatus, IncidentCategory en ResolutionSlaTargetTime. Upload het bestand of verbind de voorbereide eventbron met ProcessMind. Koppel IncidentId aan de case-identifier en ActivityName aan het activiteitsveld.

Configuratie

Triggerbereik: Configureer afzonderlijke Workflow Automator-regels voor het aanmaken van incidenten en voor elke updatevoorwaarde. Eén brede updateregel kan dubbele of onduidelijke gebeurtenissen veroorzaken, tenzij de ontvanger strikte activiteitsmapping toepast.
Webhookpayload: Neem alle verplichte attributen in elke payload op. Voeg aanbevolen attributen toe als die op het moment van de gebeurtenis beschikbaar zijn. Bewaar de onbewerkte payload voor controle en opnieuw afspelen.
Betekenis van activiteiten: Maak onderscheid tussen de eerste toewijzing van een groep of agent en latere wijzigingen. Latere wijzigingen leveren Incident Reassigned op. De eerste invulling levert de bijbehorende initiële toewijzingsactiviteit op.
Statusafhandeling: Koppel de exacte statuswaarden die in het Freshservice-account zijn geconfigureerd. Als het account aangepaste statussen voor in behandeling of open gebruikt, configureer je voor die waarden expliciete mappings.
Eerste reactie: Bepaal of een openbaar antwoord, een openbare notitie of een ander communicatietype meetelt. Pas deze definitie consequent toe en verstuur de gebeurtenis alleen voor de eerste kwalificerende communicatie per incident.
Detectie van workarounds: Configureer een speciaal veld, selectievakje, notitietype of goedgekeurde trefwoordregel. Zonder zo'n configuratie kan Workaround Provided niet betrouwbaar worden vastgesteld.
SLA-overschrijding: Configureer een expliciete trigger voor SLA-overschrijding of een afzonderlijk gepland proces dat de huidige tijd vergelijkt met ResolutionSlaTargetTime. Alleen een eindmomentopname van het incident is onvoldoende om de timestamp van de overschrijding te reconstrueren.
Datumbereik: Gebruik voor de eerste validatie ongeveer 3 tot 6 maanden aan incidenten. Start voor realtimegebruik met de gegevensinname vóór de gewenste analyseperiode en bewaar de webhookgeschiedenis om gebeurtenissen opnieuw te kunnen afspelen.
Filters: Gebruik alleen goedgekeurde filters voor bedrijf, workspace, afdeling, service, categorie of datum. Ga niet uit van Freshservice-veldnamen of filtersyntaxis die niet in de accountconfiguratie beschikbaar zijn.
Prestaties: Verwerk webhooks asynchroon, zet binnenkomende verzoeken in een wachtrij, bundel schrijfacties naar downstreamsystemen en indexeer IncidentId en EventTimestamp. Vermijd synchrone verrijkingsaanroepen tijdens de ontvangst van webhooks.
Betrouwbaarheid: Configureer nieuwe pogingen, dead-letterafhandeling, monitoring en onderdrukking van duplicaten. Leg mislukte leveringen vast en speel ze na correctie opnieuw af.
Vereisten: Beheerdersrechten, beschikbaarheid van Workflow Automator, webhookrechten, een HTTPS-endpoint, authenticatieconfiguratie, voldoende mogelijkheden binnen het Freshservice-abonnement en een ProcessMind-compatibel proces voor opslag of upload.
Beveiliging: Gebruik HTTPS, beperk inkomende toegang waar mogelijk, roteer inloggegevens, beperk gevoelige velden en bescherm incidentbeschrijvingen en notities als deze in payloads worden opgenomen.

a Voorbeeldquery config

const REQUIRED_ACTIVITIES = [
  "Incident Reported",
  "Incident Assigned to Group",
  "Agent Assigned to Incident",
  "Incident Prioritized",
  "First Response Sent",
  "Incident Reassigned",
  "Status Changed to In Progress",
  "Status Changed to Pending",
  "Workaround Provided",
  "Resolution Note Added",
  "Incident Resolved",
  "SLA Target Breached",
  "Incident Reopened",
  "Incident Closed"
];

const REQUIRED_COLUMNS = [
  "IncidentId",
  "ActivityName",
  "EventTimestamp",
  "SourceSystem",
  "LastDataUpdate",
  "AssignedAgent",
  "AssignedGroup",
  "IncidentPriority",
  "IncidentSeverity",
  "IncidentStatus",
  "IncidentCategory",
  "ResolutionSlaTargetTime"
];

function normalizeTimestamp(value) {
  if (value === null || value === undefined || value === "") {
    return null;
  }
  const date = new Date(value);
  if (Number.isNaN(date.getTime())) {
    throw new Error("Invalid timestamp: " + String(value));
  }
  return date.toISOString();
}

function textOrNull(value) {
  if (value === null || value === undefined || value === "") {
    return null;
  }
  return String(value);
}

function getField(payload, names) {
  for (const name of names) {
    if (payload[name] !== undefined && payload[name] !== null) {
      return payload[name];
    }
  }
  return null;
}

function normalizeWebhookPayload(payload, receivedAt) {
  const incidentId = getField(payload, ["IncidentId", "incident_id", "ticket_id", "id"]);
  const activityName = getField(payload, ["ActivityName", "activity_name"]);
  const eventTimestamp = getField(payload, ["EventTimestamp", "event_timestamp", "timestamp", "created_at", "updated_at"]);

  if (incidentId === null || incidentId === "") {
    throw new Error("IncidentId is required");
  }
  if (activityName === null || activityName === "") {
    throw new Error("ActivityName is required");
  }
  if (!REQUIRED_ACTIVITIES.includes(String(activityName))) {
    throw new Error("Unsupported ActivityName: " + String(activityName));
  }
  if (eventTimestamp === null || eventTimestamp === "") {
    throw new Error("EventTimestamp is required");
  }

  const row = {
    IncidentId: textOrNull(incidentId),
    ActivityName: textOrNull(activityName),
    EventTimestamp: normalizeTimestamp(eventTimestamp),
    SourceSystem: textOrNull(getField(payload, ["SourceSystem", "source_system"])) || "Freshservice",
    LastDataUpdate: normalizeTimestamp(getField(payload, ["LastDataUpdate", "last_data_update"])) || normalizeTimestamp(receivedAt),
    AssignedAgent: textOrNull(getField(payload, ["AssignedAgent", "assigned_agent", "agent"])),
    AssignedGroup: textOrNull(getField(payload, ["AssignedGroup", "assigned_group", "group"])),
    IncidentPriority: textOrNull(getField(payload, ["IncidentPriority", "incident_priority", "priority"])),
    IncidentSeverity: textOrNull(getField(payload, ["IncidentSeverity", "incident_severity", "severity"])),
    IncidentStatus: textOrNull(getField(payload, ["IncidentStatus", "incident_status", "status"])),
    IncidentCategory: textOrNull(getField(payload, ["IncidentCategory", "incident_category", "category"])),
    ResolutionSlaTargetTime: normalizeTimestamp(getField(payload, ["ResolutionSlaTargetTime", "resolution_sla_target_time"]))
  };

  for (const column of REQUIRED_COLUMNS) {
    if (!(column in row)) {
      throw new Error("Missing output column: " + column);
    }
  }
  return row;
}

function deduplicateRows(rows) {
  const seen = new Set();
  return rows.filter((row) => {
    const key = [
      row.IncidentId,
      row.ActivityName,
      row.EventTimestamp,
      row.SourceSystem
    ].join("|");
    if (seen.has(key)) {
      return false;
    }
    seen.add(key);
    return true;
  });
}

async function processWebhookBatch(webhookPayloads, receivedAt) {
  const rows = webhookPayloads.map((payload) => normalizeWebhookPayload(payload, receivedAt));
  const deduplicatedRows = deduplicateRows(rows);
  deduplicatedRows.sort((left, right) => {
    if (left.IncidentId !== right.IncidentId) {
      return left.IncidentId.localeCompare(right.IncidentId);
    }
    return left.EventTimestamp.localeCompare(right.EventTimestamp);
  });
  return deduplicatedRows;
}

module.exports = {
  REQUIRED_ACTIVITIES,
  REQUIRED_COLUMNS,
  normalizeWebhookPayload,
  deduplicateRows,
  processWebhookBatch
};

Klaar om aan de slag te gaan?

Gebruik deze template om je data goed in te richten en waardevolle inzichten in je incidentbeheerworkflows te krijgen. Werk vandaag nog aan kortere oplostijden.

Terug naar de verbetergids Template downloaden

Voorkom SLA-overschrijdingen: optimaliseer je incidentbeheer vandaag

Sluit je aan bij bedrijven die hun MTTR met 35% verlagen en kostbare SLA-overschrijdingen voorkomen.

Start je gratis proefperiode

14 dagen gratis proberen, zonder creditcard.

Jouw datatemplate voor incidentbeheer

Jouw datatemplate voor incidentbeheer

Attributen voor incidentbeheer

Incidentbeheeractiviteiten

Extractiegidsen

Data-export van de Freshservice Analytics-module naar CSV

Stappen

Configuratie

a Voorbeeldquery config

Extractie met een Python-script via de Freshservice REST API

Stappen

Configuratie

a Voorbeeldquery python

Realtime data push via webhooks van Workflow Automator

Stappen

Configuratie

a Voorbeeldquery config

Klaar om aan de slag te gaan?

Voorkom SLA-overschrijdingen: optimaliseer je incidentbeheer vandaag

Jouw datatemplate voor incidentbeheer

Jouw datatemplate voor incidentbeheer

Attributen voor incidentbeheer

Incidentbeheeractiviteiten

Extractiegidsen

Data-export van de Freshservice Analytics-module naar CSV

Stappen

Configuratie

a Voorbeeldquery config

Extractie met een Python-script via de Freshservice REST API

Stappen

Configuratie

a Voorbeeldquery python

Realtime data push via webhooks van Workflow Automator

Stappen

Configuratie

a Voorbeeldquery config

Klaar om aan de slag te gaan?

Voorkom SLA-overschrijdingen: optimaliseer je incidentbeheer vandaag

We respecteren je privacy