Variabili e modelli
Usa i dati dell'evento e dei passaggi precedenti in titoli, messaggi e richieste
Ultimo aggiornamento il
Con le variabili crei testi che cambiano da caso a caso. Scrivi una variabile tra parentesi graffe e Tillor inserisce il valore reale quando l'automazione viene eseguita.
Un esempio di titolo di un'attività:
Controleer {occupation.terrain.name}Se l'occupazione termina sul terreno 12, l'attività si chiama Controleer 12.
Inserire una variabile
Sopra ogni campo di testo in cui le variabili funzionano c'è il pulsante Variabile. Fai clic e vedi un elenco di tutti i dati disponibili, raggruppati per record. Digita per cercare (Cerca variabili) e fai clic su una riga. Tillor inserisce la variabile nel punto del cursore.
Puoi anche digitare tu stesso una variabile. Sotto il campo un riquadro grigio mostra come appare il testo con dati di esempio, così vedi subito se è corretto.
Le variabili funzionano in campi di testo come titoli, descrizioni, sottoattività, messaggi, l'ID di un cliente, di una fattura o di un altro record, il percorso o l'URL di una richiesta API, il corpo, il payload di un webhook, il nome dell'evento del webhook e i valori delle intestazioni. Negli ultimi due manca il pulsante Variabile, ma una variabile che digiti tu viene comunque compilata. Tillor non controlla questi due campi alla ricerca di errori e non mostra un esempio.
Nei campi in cui scegli un dato con cui confrontare, scrivi la variabile senza parentesi graffe. Vale per Solo quando, Se / altrimenti e Finché in Attendi finché (per esempio invoice.status), per il Campo di uno Smista e per la Data di un Ritardo.
Quali variabili esistono
| Variabile | Disponibile | Contenuto |
|---|---|---|
{occupation.…}, {invoice.…}, {task.…}, {reservation.…} e altre | Dopo un evento | I campi del record di cui parla l'evento. Il nome del record è anche l'inizio della variabile |
{occupation.terrain.name} | Dopo un evento | I campi dei record a cui rimanda il record, come il cliente o il terreno. Funziona per un livello di profondità |
{triggeredBy.name}, {triggeredBy.id} | Sempre | Il collega che ha causato l'evento. Vuoto se è stato il sistema |
{invoice.…} | Con Fattura scaduta | I campi della fattura scaduta e del cliente |
{reservation.…}, {task.…} e altre | Con Si raggiunge una data | I campi del record di cui è stata raggiunta la data, più i record a cui rimanda |
{now}, {today} | Sempre | Il momento in cui viene eseguito il passaggio e la mezzanotte di quel giorno nel fuso orario dell'organizzazione. Insieme a uno spostamento (più sotto) {today + 1 day} dà domani |
{threadId}, {messageId} | Con eventi sui messaggi della inbox, come inbox:message-created | L'ID della conversazione e del messaggio |
| I campi dell'evento | Dopo Attendi un evento, tramite Ricevuto | I dati dell'evento atteso. Sostituiscono i dati degli stessi record dall'inizio del flusso |
{createdTask.id}, {createdTask.name} | Dopo Crea attività | L'attività appena creata |
{foundTask.id}, {foundTask.name}, {foundTask.priority}, {foundTask.status} | Dopo Cerca attività, tramite Trovata | L'attività trovata dal passaggio |
{updatedTask.id}, {updatedTask.status} | Dopo Imposta stato | L'attività il cui stato è stato modificato |
{updatedTask.id}, {updatedTask.priority} | Dopo Imposta priorità attività | L'attività la cui priorità è stata modificata |
{updatedTask.id} | Dopo Aggiorna attività | L'attività che è stata modificata |
{foundDocument.id}, {foundDocument.name}, {foundDocument.status}, {foundDocument.userMetadata.documentType}, {foundDocument.userMetadata.insuranceExpiryDate} | Dopo Trova documento, tramite Trovata | Il documento trovato dal passaggio |
{updatedDocument.id} | Dopo Aggiorna documento | Il documento che è stato modificato |
{response.status}, {response.body}, {response.data.…} | Dopo Richiesta API | La risposta della richiesta |
{foundCustomer.…}, {foundInvoice.…}, {foundReservation.…} e altre | Dopo Cerca un record, tramite Trovata | I campi del record trovato dal passaggio, più i record a cui rimanda. Il nome è found più il tipo di record: foundCustomer, foundReservation, foundOccupation, foundInvoice, foundPayment, foundTerrain, foundTask, foundDocument, foundAccessMethod, foundNfcTag, foundMeter, foundInboxThread o foundInboxMessage |
{body.…}, {query.…}, {receivedAt} | Dopo Webhook in entrata | Il corpo JSON, i parametri di query e l'orario di ricezione della chiamata webhook |
| Ogni nome di destinazione di Mappa variabili | Dopo Mappa variabili | Ciò che inserisci come destinazione in quel passaggio, per esempio {invoice.displayId} dopo invoice ← {foundInvoice} |
{item.…} | Nei passaggi dopo Per ogni | I campi dell'elemento per cui il passaggio sta girando, come {item.id} |
{approvalTask.id}, {approval.decision}, {approval.label}, {approval.note}, {approval.decidedBy.name} | Dopo Chiedi una decisione, tramite un'opzione | L'attività, l'opzione scelta, il nome di quell'opzione, la nota e il collega che ha scelto |
{task.…}, {action.label}, {note} | Con Viene scelta un’azione dell’attività | L'attività, il pulsante scelto e la nota inserita |
{createdComment.id} | Dopo Aggiungi un commento | Il commento appena pubblicato |
{bookedInvoice.displayId} | Dopo Contabilizza fattura, tramite Fatto | Il numero della fattura contabilizzata |
{paymentLink.url} | Dopo Crea link di pagamento, tramite Fatto | Il link con cui il cliente può pagare online |
{consumptionInvoice.id} | Dopo Fattura i consumi, tramite Fatto | La fattura per il consumo del contatore |
{extendInvoice.id} | Dopo Bozza fattura di proroga | La bozza di fattura che prolunga l'occupazione |
{createdAccessMethod.id}, {createdAccessMethod.value} | Dopo Crea metodo di accesso | Il nuovo metodo di accesso e il suo valore, come il codice di un codice QR o di un PIN |
{error.message}, {error.step} | Dopo un'azione con Prosegui se questo passaggio non riesce, tramite Errore | Il messaggio di errore e il nome del passaggio non riuscito |
Quali campi ha esattamente un record lo vedi nell'elenco dietro il pulsante Variabile. Nel trigger c'è anche il riepilogo Dati forniti da questo evento.
Solo ciò che viene prima nel flusso
Un passaggio può usare solo variabili del trigger che lo raggiunge e dei passaggi che lo precedono sullo stesso percorso. Se più trigger raggiungono lo stesso passaggio, sono disponibili solo le variabili che ognuno di questi trigger fornisce. Un campo di un passaggio precedente conta se ognuno di questi trigger passa anche da quel passaggio. Se usi una variabile che in quel punto non esiste, Tillor segnala [Campo]: [variabile] non è disponibile in questo passaggio. Un flusso con un messaggio del genere non può essere attivato.
Alcuni record conservano dati aggiuntivi in un solo campo, come i dati del documento in userMetadata. Ogni chiave al suo interno è una variabile: {document.userMetadata.documentType}, {document.userMetadata.insuranceExpiryDate} o un'altra chiave. Le chiavi note, come il tipo e la scadenza di un documento, sono anche nell'elenco e puoi confrontarle come data. Una data senza ora, come 2026-10-07, compare in un messaggio come 07-10-2026.
Le variabili di Per ogni ({item.…}) esistono solo nei passaggi dopo l'uscita Per ogni, non dopo Completato. Anche le variabili di un'uscita che non hai preso non esistono: {paymentLink.url} c'è solo se il passaggio è passato da Fatto, e {foundTask.id} solo dopo Trovata.
Con eventi di cui i dati non sono descritti, Tillor non può verificare quali variabili esistono. In quel caso non ricevi questo messaggio. Controlla quindi questi flussi con particolare attenzione con un'esecuzione di prova.
Un nuovo valore sostituisce il vecchio
Una seconda Richiesta API nello stesso flusso sostituisce la response della prima. Lo stesso vale per createdTask dopo una seconda Crea attività, per foundTask dopo un secondo Cerca attività o Cerca un record su Attività, e per error dopo un secondo passaggio non riuscito. Usa quindi i dati di una risposta nel passaggio che segue subito.
Come vengono compilati i valori
Tillor adatta la notazione al tipo di campo.
Nel testo normale (titoli, descrizioni, sottoattività):
- Le date sono nel fuso orario della tua organizzazione, per esempio
05-10-2026. Se l'orario non cade esattamente a mezzanotte, c'è anche un'ora, come05-10-2026 14:30 - Un campo vuoto dà un testo vuoto
- Una variabile che Tillor non conosce resta come l'hai scritta, per esempio
{occupation.terain.name}. Un errore di battitura si nota così subito nell'attività o nel messaggio - Se un record collegato non c'è, la variabile resta vuota. Un'occupazione senza prenotazione non dà quindi nulla per
{occupation.reservation.displayId}, e un evento causato dal sistema non dà nulla per{triggeredBy.name}. Se in quel caso vuoi un altro testo, metti prima un Se / altrimenti con è vuoto
In JSON (il Payload di un webhook e il Corpo di una richiesta API):
- Il testo viene inserito in modo sicuro. Virgolette, a capo e altri caratteri speciali nel valore non possono rompere il JSON
- Numeri e valori sì/no vengono inseriti senza virgolette, quindi non metterle intorno. Il testo invece va tra virgolette
- Le date passano come data e ora internazionali, come
2026-10-05T08:00:00.000Z, così il sistema ricevente le gestisce bene
{
"reservation": "{reservation.displayId}",
"adults": {reservation.numberOfAdults}
}Se dopo la compilazione il JSON non è valido, per esempio perché un numero è vuoto, l'esecuzione si ferma con un messaggio di errore.
In un percorso o URL (in una richiesta API):
- I valori vengono convertiti in modo da starci in un indirizzo. Un nome con uno spazio non dà quindi un indirizzo rotto
- Anche qui le date passano come data e ora internazionali
- Ciò che digiti tu resta come lo digiti. Se vuoi uno spazio in un termine di ricerca, digita tu
%20
Spostare una data
Dopo una variabile data può esserci uno spostamento: {reservation.checkOut + 1 day}, {today - 2 weeks}, {invoice.dueDate + 3 hours|date}. Le unità sono minutes, hours, days, weeks e months (va bene anche il singolare). Giorni e settimane hanno durata fissa, così una validità resta della stessa lunghezza anche attraverso l'ora legale e solare; i mesi seguono il calendario, quindi il 31 gennaio più un mese è il 28 o 29 febbraio. Su un valore che non è una data lo spostamento non fa nulla, e un'unità che non esiste è un errore del passaggio. I campi data come Valido fino a accettano la stessa scrittura.
Formattare un valore
Dopo la variabile metti un | e un formato, per esempio {invoice.amountOutstanding|currency}. Senza formato un importo appare nudo, come 1295.3. Con |currency diventa € 1.295,30.
| Formato | Esempio | Risultato |
|---|---|---|
currency | {invoice.amountOutstanding|currency} | € 1.295,30 |
currency:USD | {invoice.amountOutstanding|currency:USD} | US$ 1.295,30 |
number | {invoice.amountOutstanding|number} | 1.295,3 |
number:2 | {invoice.amountOutstanding|number:2} | 1.295,30 (numero fisso di decimali) |
date | {invoice.dueDate|date} | 30-06-2026 |
datetime | {invoice.createdAt|datetime} | 01-06-2026 16:04 |
time | {invoice.createdAt|time} | 16:04 |
upper / lower | {customer.lastName|upper} | VAN DEN BROECKE |
- Numeri e importi sono sempre in notazione belga: un punto per le migliaia e una virgola per i decimali
- Date e orari sono nel fuso orario della tua organizzazione
- Se il formato non riesce a leggere il valore, per esempio
|currencysu un testo, il valore compare semplicemente senza formato - Un formato che Tillor non conosce resta come l'hai scritto, e l'editor mostra un avviso
- In JSON e in un URL il valore formattato viene inserito come testo. In JSON metti quindi le virgolette intorno
Usare una risposta API
Dopo una Richiesta API puoi usare i campi della risposta con {response.data.…}. La risposta di una ricerca di attività è per esempio fatta così:
{
"items": [
{ "id": "task_1", "priority": "LOW" }
]
}Allora {response.data.items.0.id} dà l'ID della prima attività (il primo di un elenco è il numero 0) e {response.data.items.0.priority} la sua priorità.
Tillor può offrire i campi di una risposta come variabili solo se sa com'è fatta la risposta. Ci sono due modi:
- Fai girare davvero l'automazione una volta. Tillor usa allora la risposta dell'ultima esecuzione
- Incolla un esempio nella scheda Esecuzione di prova, nel campo Esempio di risposta API. Il campo compare non appena il flusso contiene una Richiesta API. Sotto ci sono i Campi di questa risposta. Fai clic su un campo per copiarlo, parentesi graffe incluse
Poi i campi compaiono nell'elenco dietro il pulsante Variabile e nell'elenco di Campo di uno Smista.
Se digiti tu un percorso sotto response.data, viene sempre accettato, anche senza esempio. Inoltre:
{response.body}contiene i primi 4000 caratteri della risposta. Se la risposta è più lunga, il resto viene tagliato{response.data}è vuoto se la risposta non è JSON o se la risposta è molto grande (oltre 100.000 caratteri)- Con una ricerca senza risultati
{response.data.items.0.id}non esiste. Uno Smista su un campo del genere passa allora da Predefinito
Un esempio nella prova
Nella scheda Esecuzione di prova inserisci anche i dati di esempio dell'evento. Così nell'esecuzione di prova vedi quali valori Tillor inserirebbe. Vedi Prove ed esecuzioni.
Cosa succede poi?
- Non appena l'automazione viene eseguita, Tillor sostituisce ogni variabile con il valore reale. Una variabile che Tillor non conosce resta come l'hai scritta.
- Se un dato è vuoto, il posto resta vuoto. Se allora vuoi un altro testo, metti prima un Se / altrimenti con è vuoto.