Feltnøkler

Hvorfor de finnes

Uten feltnøkler må en automatisering adressere spørsmålene dine med interne ID-er som ikke betyr noe for noen — og en webhook-nyttelast kommer full av dem. Med feltnøkler leser begge sider samme språk:

{ "company_name": "Acme", "employees": 120, "contacts": [{ "name": "Ada" }] }

Feltnøkler brukes to steder: prefill, context, og readonly når du oppretter en forespørsel; og answers- og display-kartene i hver callback og hver webhook-nyttelast.

Hvor du finner dem

Hver nøkkel skjemaet publiserer, lever ett sted, Nøkler-tabellen: hvert felt, og under et valgspørsmål hvert alternativ, under en matrise hver rad og kolonne. Den avsluttes med en forhåndsvisning av answers-objektet callbacken din vil bære, med dine nøkler i seg.

1. 1

   Åpne den

   Klikk på nøkkel-ikonet i editorens verktøylinje (eller Nøkler i verktøylinjens overflytmeny på et smalt vindu). Tabellen åpnes i et sidepanel over hele skjemaet.

2. 2

   Les plassholderen

   Når et inndatafelt er tomt, viser plassholderen nøkkelen feltet faktisk svarer til — nøkkelen det ble publisert under hvis skjemaet er live, ellers nøkkelen utledet fra dagens tittel eller etikett. Skriv for å overstyre den; tøm feltet for å gå tilbake.

Hver hint-rad under et alternativ — den grå linjen under alternativet du redigerer — avsluttes med nøkkelen dets som en chip. Klikk på chippen for å redigere nøkkelen direkte, trykk Enter eller Escape når du er ferdig. En matrise viser chippen for raden eller kolonnen hvis etikett du redigerer. En chip blir gul når skjemaet er publisert og nøkkelen du skrev inn, ville flyttet den automatiseringer allerede bruker.

Den samme tabellen vises skrivebeskyttet der du kobler til en integrasjon: under webhookens feltoppsett, og under forespørselutdragene i Del-vinduets Forespørsler-kort. Du kan også lese alle nøklene på én gang med fields.list.

Hvordan en nøkkel utledes

Du trenger ikke sette noe selv. Til du redigerer den, utledes en nøkkel fra spørsmålets tittel: aksenter felles ut og bokstaver som ø, æ og ß blir til o, ae og ss, alt gjøres til små bokstaver, hver sammenhengende sekvens som ikke er en bokstav eller et siffer blir én enkelt understrek, ledende og etterfølgende understreker fjernes, og resultatet kuttes til 64 tegn.

En tittel som bare er skrevet med et ikke-latinsk skriftsystem, for eksempel arabisk, hebraisk, kyrillisk, gresk, kinesisk eller japansk, har ingenting som kan felles ut. Nøkkelen er derfor field_ pluss posisjonen, og nøkkelen til et alternativ er option_ pluss posisjonen. Etter publisering er disse nøklene like stabile som alle andre, men de sier ingenting om spørsmålet. Når en automatisering leser svarene, bør du sette en lesbar nøkkel selv i Nøkler-tabellen.

Hvis to felt ville endt opp med samme nøkkel, bryter formbase uavgjort i dokumentrekkefølge ved å legge til _2, _3, og så videre. En nøkkel du setter selv vinner alltid sitt krav, og den utledede viker.

Sette din egen nøkkel

Skriv et navn i Feltnøkkel-feltet for å overstyre den utledede. Å tømme feltet går tilbake til den utledede nøkkelen. Tillatte tegn er bokstaver, sifre, _, . og -, opptil 64 tegn — alt annet avvises med «Bruk bare bokstaver, tall og _ . - (maks 64 tegn).» Mellomrom gjøres om til understrek mens du skriver, så «kontaktnavn» blir kontaktnavn.

Nøkler skiller mellom store og små bokstaver og må være unike innenfor ett skjema. Å gjenbruke en nøkkel som allerede er tatt av et annet spørsmål, en gjentakende gruppe, et skjult felt eller et beregnet felt, avvises med «Et annet felt bruker allerede denne nøkkelen.»

Nøkler fryses ved første publisering

Første gang du publiserer, skrives hvert felts nøkkel inn i den publiserte versjonen. Hver senere publisering fører de samme nøklene videre, som betyr:

• Ny tittel flytter aldri en nøkkel. Gi nytt navn fra «Company name» til «Legal entity name», og nøkkelen forblir company_name. Automatiseringene dine fortsetter å fungere; bare ordene på siden endres.

• Å endre et spørsmåls type flytter aldri en nøkkel. Å gjøre om et tekstspørsmål til en nedtrekksliste beholder nøkkelen — selv om verdiformen automatiseringen din må sende, endres med den.

• Å flytte et spørsmål flytter aldri nøkkelen dets. Posisjon betyr bare noe for det posisjonelle reservevalget på et felt uten brukbar tittel.

• Å duplisere en blokk gir kopien en ny nøkkel. En nøkkel du satte selv kopieres og gis ny nøkkel til neste ledige _2; utledede nøkler gjøres unike ved publisering.

• Skjemaer bygget før feltnøkler eksisterte får sine ved neste publisering.

Publisering er også der nøkkelkollisjoner fanges opp, og begge stopper publiseringen i stedet for å stille gi et felt nytt navn:

• To felt som krever samme nøkkel — Field key “…” is used by more than one field.

• En nøkkel du skrev inn på ett felt som et annet felt allerede har publisert —

  Field key “…” is already published on “…”. Giving it to “…” would rename that field’s key to “…_2” and break automations using “…”.

  Frigjør nøkkelen på ett av de to feltene og publiser på nytt.

Begge vises ved siden av Publiser-knappen sammen med alle andre funn fra klargjøringssjekken — se Publiseringssjekker.

Når en publisert nøkkel er i ferd med å forsvinne

En nøkkel tilhører feltet den ble publisert på, ikke tittelen dets. Så det finnes to måter å miste en nøkkel på uten å mene det: skrive inn en annen nøkkel på et publisert felt, eller slette et spørsmål og legge til et nytt i stedet. Det nye spørsmålet er et nytt felt — det får en fersk nøkkel utledet fra sin egen tittel, og den gamle nøkkelen er borte.

Ingenting feiler på formbase sin side når dette skjer. Webhooken utløses fortsatt og callbacken kommer fortsatt frem, bare uten det svaret, og requests.create begynner å avvise den gamle nøkkelen med UNKNOWN_FIELD_KEY. Så publisering sjekker for dette først. Når en nøkkel den live versjonen publiserer, ikke ville eksistert i den neste, viser publiseringsdialogen og problemindikatoren ved siden av Publiser-knappen en advarsel:

Feltnøkkelen "company_name" finnes ikke lenger etter denne publiseringen. Integrasjoner og forespørsler som bruker den, slutter å motta det svaret. Et nytt felt "Company" publiseres som "company". Sett feltnøkkelen til "company_name" for å holde dem i gang.

• For å holde automatiseringene dine i gang, åpne Nøkler-tabellen, finn feltet advarselen navngir, og skriv inn den gamle nøkkelen. Advarselen forsvinner og nøkkelen fortsetter som om ingenting hadde skjedd.

• Hvis du fjernet feltet med vilje, publiser likevel — det er en advarsel, ikke en feil — og oppdater automatiseringene som leser nøkkelen.

• Advarselen navngir et felt bare når valget er opplagt: feltet hvis nøkkel du skrev inn på nytt, eller det ene nye feltet som står der ett enkelt slettet felt sto. Ellers navngir den bare nøkkelen.

• Å slette en gjentakende gruppe gir en advarsel for gruppens nøkkel og for nøkkelen til hvert felt inni den. Publisering gjennom MCP-serverens form_publish returnerer de samme meldingene i warnings.

• Alternativ-, rad- og kolonnenøkler får samme behandling: slett et alternativ eller skriv om nøkkelen dets på et publisert skjema, og publisering advarer Alternativnøkkelen “pro” for “Plan” finnes ikke lenger etter denne publiseringen, og navngir nøkkelen alternativet publiseres som nå, når det fortsatt finnes. Publiseringsdialogen lister alle nøkkelendringer, på begge nivåer, under Nøkler som endres i denne publiseringen.

Gjentakende grupper og skjulte felt

En gjentakende gruppe har sin egen nøkkel, og det har hvert felt inni den også. Automatiseringer adresserer gruppen som helhet og nester medlemmene:

{ "contacts": [{ "name": "Ada", "email": "ada@acme.com" }, { "name": "Grace", "email": "grace@acme.com" }] }

Et felt inni en gruppe er bare tilgjengelig gjennom gruppen sin — det finnes ingen name på toppnivå her, bare contacts[0].name. Gi nytt navn til gruppens nøkkel, og hele arrayen flytter med; gi nytt navn til ett medlems nøkkel, og bare det navnet inni hvert objekt endres.

Et skjult felts parameternavn er feltnøkkelen dets. Det er nøkkelen du legger i context når du oppretter en forespørsel, og det samme navnet du ville brukt i en URL-parameter på en offentlig lenke.

Et beregnet felts navn er feltnøkkelen dets, og det deler skjemaets ene sett med nøkler med alt annet. Det er skrivebeskyttet: skjemaet regner ut verdien selv, så du kan aldri sende inn ett — fields.list lister det med calculated: true, og requests.create avviser det i prefill og context. Du leser det derimot tilbake: det kommer i answers under navnet sitt (answers.total). Å gi nytt navn til et publisert beregnet felt gir nytt navn til nøkkelen dets, med samme publiseringsadvarsel som ethvert annet felt.

Alternativnøkler: valgene inni et spørsmål

Delene av et spørsmål som et svar navngir, får nøkler også. Hvert alternativ i et radio-, select-, checkbox-, bildevalg- eller rangeringsspørsmål, og hver rad og kolonne i en matrise, har en alternativnøkkel: utledet fra etiketten dets på samme måte som en feltnøkkel utledes fra en tittel, redigerbar, og fryst ved publisering. Så et svar leses som et navn på begge sider:

{ "plan": "pro", "interests": ["billing", "api"], "satisfaction": { "delivery_speed": "very_good" } }

En arbeidsflyt forgrener seg på answers.plan == “pro” uansett hvilket språk respondenten svarte på, og en forespørsel forhåndsutfyller et valg med { "plan": "pro" }. Nøklene listes av fields.list under hvert felts options, eller en matrises rows og columns, og redigeres i Nøkler-tabellen eller på alternativets chip. Hvert spørsmåls alternativer er sitt eget navnerom, så to spørsmål kan begge ha en yes, og en matrises rad og kolonne kan dele en nøkkel. To alternativer på ett spørsmål som ville utledet samme nøkkel, skilles med _2, som felt.

Beslutningsspørsmålet er en vanlig radioknapp hvis tre alternativer bærer nøklene approve, decline og changes; det er det som gjør en forespørsels outcome til et lukket sett.