← Tutte le guide

Rispondere · Guida operativa

Confermare una domanda alla volta

In modalità micro «Conferma risposta» invia e rende definitiva la domanda corrente. Il server stabilisce quando la successiva è disponibile; il testo digitato senza conferma rimane soltanto locale.

Per chi: Rispondente · Ospite

Prima di iniziare

  • Un tentativo micro avviabile nella finestra prevista.
  • Conoscere l'intervallo e l'eventuale possibilità di rinvio della propria campagna.

Passo dopo passo

  1. Apri l'attività e leggi domanda, avanzamento e avvisi. Numero e progresso contano le domande applicabili già confermate dal server, senza avanzare per una selezione locale. Campione e ordine rimangono quelli congelati nel tentativo.
  2. Inserisci e ricontrolla la risposta, poi scegli «Conferma risposta». In micro non c'è il salvataggio automatico temporizzato della modalità completa: digitare o attendere non registra la risposta sul server. Il refresh perde la parte non confermata.
  3. Dopo la conferma controlla la prossima disponibilità. Quando compare lo stato di attesa o «Sei al passo», non serve inviare ripetutamente la risposta precedente.
  4. Se «Rimanda» è disponibile, controlla l'effetto sulla prossima disponibilità prima di usarlo. Il rinvio non conferma la risposta digitata, non la conserva come bozza server e non crea una nuova ricorrenza o un nuovo tentativo.
  5. Riapri l'indirizzo con «?attempt=» quando l'attività è disponibile. Rileggi soltanto le risposte già confermate; dopo l'ultima conferma attendi la ricevuta server. Nel portale del proprio account la ritrovi anche dall'elenco; come ospite leggi quella immediata e termina la sessione.

Risultato atteso

Le risposte confermate avanzano il tentativo fino al completamento, con disponibilità governata dal server.

Limiti e recupero

  • Pausa e policy di conclusione possono cambiare l'accesso; non si aggirano ricaricando.
  • Una conferma in conflitto richiede di rileggere lo stato prima di riprovare. Rilettura, refresh o uscita con scarto perdono la risposta locale non confermata; un tentativo invalidato rimane nello storico.
  • L'ospite completato perde l'accesso runtime: il refresh non promette di recuperare la ricevuta. La ricevuta immediata e quella del portale del proprietario sono contesti diversi.
← All guides

Respond · Practical guide

Confirm one question at a time

In micro mode, Confirm answer submits and finalises the current question. The server determines when the next becomes available; input entered without confirmation remains local.

For whom: Respondent · Guest

Before you start

  • A micro attempt available within its configured time window.
  • Awareness of the campaign interval and any permitted postponement.

Step by step

  1. Open the activity and read its question, progress and notices. The number and progress count applicable questions already confirmed by the server; local input does not advance them. The sample and order remain frozen into the attempt.
  2. Enter and inspect the answer, then choose Confirm answer. Micro mode does not use the full form’s timed autosave: typing or waiting does not record the answer on the server. Refreshing loses unconfirmed input.
  3. After confirmation, inspect the next availability. When a waiting state or You are up to date appears, repeatedly submitting the previous answer is unnecessary.
  4. If Postpone is available, inspect its effect on the next availability before using it. Postponement does not confirm the entered answer, retain it as a server draft or create another recurrence or attempt.
  5. Reopen the address with ?attempt= when the activity becomes available. It restores only confirmed answers; after the final confirmation, wait for the server receipt. In your account’s portal it is also available from the list; as a guest, read the immediate receipt and end the session.

Expected result

Confirmed answers advance the attempt to completion, with availability controlled by the server.

Limits and recovery

  • Pausing and finish-started policies can change access; reloading cannot bypass them.
  • A confirmation conflict requires rereading current state before retrying. Reloading, refreshing or leaving with discard loses unconfirmed local input; an invalidated attempt remains in history.
  • A completed guest loses runtime access: refreshing does not promise receipt recovery. The immediate receipt and the owner’s portal receipt are different contexts.
Apri immagine originale