Afgræns, hvad Airtables seneste ændring skal måle
En ordreoversigt viser nye oplysninger fra en kundetabel, men datoen for seneste ændring står stille. Det kan være forventet i Airtable. Tidspunktet afhænger af de felter og poster, som målingen faktisk følger.
Følg det felt, der bærer beslutningen
Last modified time og LAST_MODIFIED_TIME() følger ændringer i redigerbare felter. Automatiske ændringer i eksempelvis formler og rollups registreres ikke direkte. Funktionen kan afgrænses til et bestemt felt, eksempelvis LAST_MODIFIED_TIME({Status}).
Vores anbefaling er at navngive datoen efter den konkrete betydning: Status senest ændret er mere brugbart end Senest behandlet, hvis kun statusfeltet følges. Til en ordre med beregnet leveringsdato bør I afklare, om det er kildedatoen eller en egentlig godkendelse, der skal udløse opfølgning.
Se ændringer i den tilknyttede tabel
Tilføjelse eller fjernelse af en tilknyttet post ændrer tidspunktet. Ændring af felter inde i den tilknyttede post gør ikke. Airtable beskriver, at tidspunktet kan registreres i den anden tabel og hentes ind med lookup eller rollup.
Et illustrativt tilfælde er en ændret leveringsadresse på kunden. Afklar, om ordren skal følge den aktuelle stamadresse eller bevare adressen fra bestillingen. En teknisk dato løser ikke det valg. Lad den ansvarlige for ordreprocessen bestemme betydningen, før målingen bygges.
Prøv også en rettelse, der fortrydes
Hvis en værdi ændres og derefter ændres tilbage, viser Last modified time tidspunktet for tilbageføringen. Den oprindelige dato bliver ikke genskabt.
Lav en prøve med en statusændring, en ændring i kundetabellen og en tilbageført værdi. Skriv de forventede datoændringer ned på forhånd. Hvis teamet behøver en forklaring på hele forløbet, bør det bevare relevant historik særskilt; ét tidspunkt kan ikke fortælle, hvilke værdier der stod der undervejs.