Google Workspace CLI för nybörjare: skapa och kontrollera ett feedbackformulär

Ett feedbackformulär kan se färdigt ut trots att en fråga hamnat fel eller svarslänken blivit öppnare än tänkt. I den här guiden bygger du därför ett opublicerat Google Forms-formulär med fyra frågor och kontrollerar den sparade versionen innan någon får tillgång till det.

Exemplet är ett tvåminutersformulär efter en AI-workshop. Du arbetar med Google Workspace CLI, gws, utan att skriva ett eget API-program. Räkna med 10–15 minuter när verktyget redan är installerat och autentiserat. Första OAuth-konfigurationen kan ta längre tid.

Det här ska vara klart när du är färdig

Formuläret innehåller fyra frågor i en bestämd ordning:

1. en obligatorisk skala från 1 till 5 om hur tydligt nästa steg var;
2. ett obligatoriskt val om vad deltagaren vill använda först;
3. en valfri fritextfråga om vad som behöver bli tydligare;
4. en obligatorisk ja- eller nej-fråga om nästa guide.

Sedan kontrollerar du titel, antal frågor, ordning, frågetyper, obligatoriska fält, e-postinsamling och åtkomst. Formuläret ska fortfarande vara opublicerat när guiden slutar.

Innan du börjar

Du behöver ett Google-konto, ett Google Cloud-projekt och OAuth-åtkomst till de Forms- och Drive-operationer som används. Installera aktuell version från projektets instruktioner. Med Node.js kan du använda:

npm install -g @googleworkspace/cli

Första konfigurationen kan startas med gws auth setup. Därefter väljer du bara de tjänster som arbetsflödet behöver:

gws auth login -s forms,drive
gws --version

gws ligger i Googles googleworkspace-organisation på GitHub, men projektet säger uttryckligen att det inte är en officiellt supportad Google-produkt. Det är dessutom pre-v1, så kontrollera version och hjälptext innan du kopierar äldre kommandon. Den här körningen testades med gws 0.22.5 den 19 augusti 2026.

Källa: Google Workspace CLI på GitHub.

Låt verktygets inloggning eller operativsystemets nyckelring hantera autentiseringen. Klistra inte in OAuth-token eller klienthemligheter i frågefiler, chattar eller skärmbilder.

Steg 1: skriv frågespecifikationen först

Börja med innehållet, inte kommandot. En kort specifikation gör den senare kontrollen enkel:

[
  \{"index": 0, "type": "scale_1_5", "required": true\},
  \{"index": 1, "type": "single_choice", "required": true\},
  \{"index": 2, "type": "paragraph", "required": false\},
  \{"index": 3, "type": "yes_no", "required": true\}
]

Fyra blandade frågetyper räcker för att prova arbetsflödet. Du behöver inte göra formuläret större för att lära dig metoden.

Steg 2: skapa ett opublicerat skal

Spara den första kroppen som form-create.json:

\{
  "info": \{
    "title": "AI-workshop: tvåminuters återkoppling"
  \}
\}

Skapa formuläret med unpublished=true:

gws forms forms create \
  --params '\{"unpublished":true\}' \
  --json "$(<form-create.json)" \
  --format json

Spara det returnerade formulär-ID:t lokalt som FORM_ID, men lägg det inte i en offentlig skärmbild. Den första anropet skapar bara formulärets skal. Frågor och beskrivning läggs till i nästa steg.

Google dokumenterar att API-skapade formulär efter den 30 juni 2026 är opublicerade som standard. Här skickar vi ändå unpublished=true uttryckligen, eftersom äldre referenstext och dynamisk hjälp inte är helt samstämmiga om standardvärdet.

Källa: Create a form or quiz.

Steg 3: lägg till frågorna i en ordnad batch

Skapa questions.json med en updateFormInfo-begäran följd av fyra createItem-begäranden. Varje fråga får platsen 0, 1, 2 eller 3. Den valfria fritextfrågan har required: false, medan de övriga har required: true.

Kör sedan hela kroppen i ett anrop:

gws forms forms batchUpdate \
  --params "\{\"formId\":\"$FORM_ID\"\}" \
  --json "$(<questions.json)" \
  --format json

Ordningen spelar roll. Google Forms API validerar begärandena en i taget. Index 1 är inte giltigt förrän index 0 finns. Om en beroende begäran är fel skrivs inte de andra ändringarna i batchen.

Källa: Update a form or quiz.

Steg 4: läs tillbaka det sparade formuläret

Ett lyckat uppdateringsanrop bevisar inte att rätt innehåll sparades. Hämta därför formuläret igen:

gws forms forms get \
  --params "\{\"formId\":\"$FORM_ID\"\}" \
  --format json > form-readback.json

Gör sedan en kort mänsklig kontroll i stället för att bara skumma hela JSON-svaret:

• titeln stämmer;
• exakt fyra frågor finns;
• ordningen är skala, ett val, fritext, ja eller nej;
• obligatoriska fält är ja, ja, nej, ja;
• emailCollectionType är DO_NOT_COLLECT.

JSON kan utelämna booleska standardvärden som är false. Den valfria frågans saknade required-fält ska därför tolkas som falskt enligt API-modellen, inte som att kontrollen hoppades över.

I Hammers test matchade alla fyra frågor och alla obligatoriska fält. Formulär-ID, svarsadress och kontoidentifierare har tagits bort från det publika underlaget.

Steg 5: kontrollera publicering och svarsåtkomst var för sig

Ett formulärs publiceringsstatus och dess publicerade Drive-behörigheter är två olika kontroller. Lista därför behörigheterna i den publicerade vyn:

gws drive permissions list \
  --params "\{\"fileId\":\"$FORM_ID\",\"includePermissionsForView\":\"published\",\"fields\":\"permissions(id,type,role,view)\"\}" \
  --format json

Leta efter en behörighet med view=published och role=reader. Om en sådan öppen läsbehörighet finns ska den tas bort med dess behörighets-ID, och listan ska hämtas igen:

gws drive permissions delete \
  --params "\{\"fileId\":\"$FORM_ID\",\"permissionId\":\"$PERMISSION_ID\"\}"

Publicera inte formuläret och skicka inte ett fejksvar bara för att testa. I den verifierade körningen återstod bara ägarbehörigheten, och ett anonymt försök att öppna svarsadressen gav HTTP 401. Det är bevis för just den artefakten, inte ett löfte om att alla stängda formulär svarar med samma statuskod.

Källor: API changes to Google Forms. Publish and manage responders on the form.

Spara en kort kontrollista

Innan du går vidare ska du kunna bocka av:

• [ ] rätt titel;
• [ ] exakt fyra frågor;
• [ ] rätt ordning och frågetyper;
• [ ] rätt obligatoriska fält;
• [ ] e-postinsamling enligt avsikt;
• [ ] publiceringsstatus granskad;
• [ ] publicerade läsbehörigheter granskade;
• [ ] ingen riktig respondent har använts.

Fyra vanliga misstag

1. Försöka lägga frågorna i det första create-anropet. Skapa skalet först och använd sedan batchUpdate.
2. Skicka indexen i fel ordning. Lägg till 0 före 1, 1 före 2 och så vidare.
3. Lita på ett lyckat mutationssvar. Hämta alltid den sparade versionen med forms.get.
4. Behandla "opublicerat" och "ingen svarsåtkomst" som samma sak. Kontrollera både Forms-status och Drive-behörigheter.

Nästa steg efter ett godkänt formulär

Den här guiden slutar före publicering. Ett senare arbetsflöde kan lägga till namngivna respondenter, öppna och stänga svarsmottagningen och logga varje ändring, men det behöver provas separat.

Skapar ni samma formulär efter varje utbildning? Hammer kan hjälpa er bygga ett repeterbart flöde med avgränsad åtkomst, kontrollpunkter och tydlig loggning.