Sliick Forms: Complete User Guide

Version: written for Sliick Forms v0.4.0, live and free on the Salesforce AppExchange. This guide is cumulative: it covers everything in the product today.

Feedback shapes 1.0. The product is complete enough to run production intake today, and we are collecting feedback to decide what goes into 1.0. If something here does not match what you see, or you need the product to do something it does not, write to support@Sliick.com.

Sliick Forms is a native Salesforce form engine. Admins build a form in a drag-and-drop builder, map each field to an object and field, and publish it. Respondents fill it in on an Experience Cloud page, whether that page is behind portal login or open to the public. Every submission stages inside your org first, so you can review what it will write before it writes it, and then lands on the right record.

There is no middleware, no export and re-import, and no third-party service holding your respondents’ answers.

Guide overview

1. What Sliick Forms is, and how it fits together
2. Install and permission sets
3. The admin workspace
4. The Admin Dashboard
5. Create a form
6. The Form Builder
7. Building with drag and drop
8. Field types
9. Pages
10. Sections, columns, and repeating groups
11. Visibility rules
12. The Logic Map
13. Mapping fields to Salesforce
14. Matching: update instead of duplicate
15. Record types
16. Form settings
17. Accepting responses
18. Sharing a form
19. Publishing, versions, and A/B experiments
20. Working with responses
21. Results, funnels, and NPS
22. Public forms on Experience Cloud
23. Guest access for public forms
24. Blueprints, ALM, and moving forms between orgs
25. Retiring or deleting a form
26. Troubleshooting
27. Getting help

What Sliick Forms is, and how it fits together

The product is made up of four things, and knowing which is which makes the rest of this guide easier to follow.

Two distinctions are worth understanding before you start.

A draft is not a published version. Editing a form never changes what respondents are filling in at the time. Publishing is the separate step that makes your work live, and every version you have published stays available to compare against or restore from.

A submission is not the records it creates. Answers land in the org as a staged submission first. Processing is the step that maps them onto Contacts, Cases, Leads, or whatever else you targeted, and you can preview what processing will do before you run it.

Install and permission sets

Install the package

Install Sliick Forms free from the AppExchange listing and choose Install for Admins Only. You will grant access explicitly with permission sets in the next step, so installing for all users grants nothing extra and only widens the tab surface.

Confirm the install under Setup, Installed Packages: Sliick Forms should appear with the expected version and the sliick namespace.

What the package needs:

Permission sets

No packaged permission set is assigned automatically. Assign them yourself.

sf org assign permset --name Sliick_Forms_Admin --target-org <alias>

Or use Setup, Permission Sets, select, Manage Assignments.

Three things worth knowing about the access model:

• Sliick Forms User does not include the responses console. The richer surface with filtering, CSV export, reprocessing, corrections, and analytics is part of Sliick Forms Admin only. A Sliick Forms User reviewer sees the plain list and detail view of submission records.
• Never assign Sliick Forms User to an external or guest persona. It grants view-all on submissions, which is an internal-staff grant.
• No packaged permission set grants create access on the submission object. That is intentional and explained under Guest access.

The admin workspace

Open the App Launcher, search for Sliick Forms Admin, and open the app. It carries four tabs:

The first two split cleanly: the dashboard is where forms live, the builder is where a form is edited. Finding, creating, duplicating, and importing forms all happen on the dashboard. Once you open a form, everything about that form happens in the builder.

The Admin Dashboard

Overview tiles

Five counts across the top: Forms (with how many are accepting responses), Published (how many serve a pinned version), Responses in the last 7 days (excluding test submissions), Failed processing, and Experiments. The Failed processing tile is clickable when the count is above zero and takes you to the responses console already filtered to failures.

Finish setup: the public base URL

Until an org-wide base URL is set, a Finish setup strip sits under the tiles. Enter your address in Public base URL and click Save. Once saved, the strip collapses to a single line of fine print showing the value, with a Change link.

Put {form} where a form’s external ID belongs, so one setting serves every form. For example, https://acme.my.site.com/forms/f?form={form} points at a single Experience Cloud page that serves your whole catalogue.

A value with no {form} placeholder simply has /<external id> appended to it. A single trailing slash is trimmed when the value is saved.

This writes the same setting as Setup, Custom Settings, Forms Settings. Note the two spellings: the dashboard says Public base URL, the custom setting field is labelled Public Site Address.

Needs attention

When there is anything to act on, a Needs attention panel lists it: failed submissions, a running experiment, a form closing within seven days, and forms at or near their response cap. Each row carries the action that resolves it, either Review in Console or Open in Builder. It is computed over every form in the org, not only the ones your current search and folder filter show.

The forms table

Below that, every form in the org, one row each:

Above the table sits a Search forms box matching external ID or name, a folder filter, a sort control offering Recently edited (the default), Name A to Z, and Most responses, a New Form button, and an Import blueprint file picker. When a real folder is selected, a Rename folder button appears. Renaming moves every form in the folder, and renaming onto a folder that already exists merges the two.

The status badges are read-only here. Pausing or resuming a form is done in the builder.

Create a form

1. Click New Form on the dashboard.
2. Either pick a ready-made starter, each listing the fields it creates, or choose Start blank:
   • Contact form
   • Event registration
   • NPS survey
   • CSAT survey
   • Customer effort survey
3. A blank form asks for a Form name, and derives the External ID for you. Contact Us - Sales! becomes contact_us_sales. You can edit the derived value, and if the one you type is already taken you get a message naming the conflict rather than a database error.
4. Either way you land in the Form Builder on the new form, filed into whichever folder you were looking at.

The external ID is fixed once the form is created. It is the long-lived key that blueprint import and export depend on, and every public link is built from it. The only chance to choose it is at creation. Change the name freely afterwards, but keep the slug stable and environment-neutral.

To copy an existing form, use Duplicate in its row. The copy is created paused, with a _copy_ prefix on its external ID, and you stay on the dashboard.

The Form Builder

The builder is three columns:

1. Fields palette on the left: the field types you can add, grouped Basic, Choice, Advanced, and Layout, with a search box above them.
2. Canvas in the middle: your form rendered on a sheet, the way a respondent will see it, one card per field. Editing controls appear when you point at a card.
3. Field Settings inspector on the right: what the selected block is, and only what it can change, with a sticky Save, Duplicate, and Delete footer and an Unsaved changes chip when you have pending edits.

Across the top: the back arrow to the dashboard, the form name and draft status, the Canvas and Logic Map view toggle, the Accepting responses state pill, undo and redo, the save indicator, the settings gear, Preview form, and Publish. Above the canvas sits the page tab bar.

The builder edits one form and has no form picker of its own. Open a form by clicking its row on the dashboard. Opening the Form Builder tab directly, with no form chosen, shows a small placeholder and a Go to Admin Dashboard button. That is expected. The back arrow returns you to the dashboard, saving any pending edit on the way.

Everything you do in the builder runs against the form’s draft and autosaves. Respondents see nothing until you publish.

Building with drag and drop

Add a field at an exact position

1. Point at a field type in the Fields palette.
2. Press and drag it onto the canvas.
3. As you drag over the existing cards, a blue drop indicator shows exactly where the field will land.
4. Release to insert it there. The new field is selected automatically so you can configure it straight away.

Mid-drag: the blue indicator shows the Number field will be inserted just above Email.

After the drop: the field landed where the indicator promised, and is selected.

A plain click on a palette field also works and always appends to the end of the form. Drag when position matters, click when it does not.

Add a field at the end

The canvas has an end dropzone below the last card labelled Drop here to add at the end. Drag a palette field onto it to append. You can also drag an existing card onto it to move that card to the end. The dropzone stays inert if the block you are dragging is already last, because that move would do nothing.

On an empty form the end dropzone fills the whole canvas and shows the hint Add fields from the palette to start building this form.

Reorder a field

Point at the grip handle at the left edge of a card, drag the card up or down, and release where the blue indicator sits. The up and down arrow buttons on a card do the same thing one step at a time.

Dragging a structural marker (Section, Repeating Group, Columns row) moves the marker together with its whole block, not the marker on its own.

Page dividers are the exception: they are not draggable, and nothing can be dropped above the first one. Pages are managed from the tab bar instead.

Remove a field

Three ways, and they differ in how much they remove:

The delete icon is keyboard reachable: Tab to it and press Enter or Space. There is no confirmation dialog, because every deletion is undoable.

Block-aware means:

• Section: through to the next Section or page divider.
• Repeating Group: through its matching End Repeat marker.
• Columns row: through its matching End Row marker.
• A plain field: just that field.

Page dividers have no delete icon. Pages are deleted from the tab bar, which confirms first because deleting a page deletes its fields.

Undo a deletion

When you delete a block containing more than one element, a snackbar appears at the bottom of the canvas naming what was removed, with an Undo button.

The count is the number of fields you saw inside the block. Structural end markers are not counted, so a repeating group wrapping two fields reads “and 2 fields”, not three. Click Undo to restore the whole block in its original position.

The snackbar dismisses itself after about six seconds and a newer deletion replaces it. Cmd/Ctrl+Z undoes at any time, whether or not the snackbar is still showing. Single-field deletions raise no snackbar: they are obvious on screen and just as easily undone.

Cancel a drag

Press Escape, or release the pointer anywhere that is not a valid drop target. The drop indicator, the palette highlight, and the remove hint all clear cleanly, and nothing changes on the form.

Undo, redo, and autosave

Every drag action (insert, reorder, and delete) is a normal edit:

• It participates in undo and redo. Cmd/Ctrl+Z undoes, Cmd/Ctrl+Shift+Z redoes.
• It autosaves to the form’s draft shortly after the change, so you never save manually while authoring.

Drag-and-drop authoring works in Chrome, Edge, and Firefox.

Field types

The palette is grouped, and the palette itself is the current source of truth: it changes more often than any document does.

Every field carries a Label, an API Name, a Required toggle, an optional Salesforce mapping, and collapsible Display, Visibility, and Validation sections in the inspector. Validation covers minimum and maximum length or value, a pattern, and the message a respondent sees when the pattern fails.

There are deliberately no Name or Address composite types. They could only ever expand into primitive fields, so place those fields and map each one. The mapping picker makes that quick by pre-scoping to the form’s dominant object.

A few palette items carry a green tint: File Upload, Signature, Payment, GPS Location, and Barcode. The tint groups the blocks that need the full form to run, and all of them are fully supported wherever you place a form today. It is a category label rather than a warning.

Pages

Every form has at least one page, and pages are managed from the page tab bar across the top of the canvas. The bar is always there, even on a single-page form.

• All pages shows the whole form, each page rendered as its own sheet so the breaks are visible as you scroll.
• Each page tab filters the canvas to that page and shows how many fields are on it.
• The page toolbar to the right of the tabs acts on the selected page: settings, duplicate, and delete. It is empty on All pages, leaving just + Add page, which is always available.
• A tab reading Hidden by rule means that page’s visibility rule is false for the test answers currently on the canvas, so a respondent would skip it. Its fields are dimmed to match.

Add a page. Click + Add page. The new page is appended to the end and becomes the active tab, so the next field you add lands on it. New pages show as Page 2, Page 3, and so on. That number is the page’s position, so it keeps up automatically as you add or delete pages around it.

Rename a page or give it a rule. Select its tab and click settings. The inspector switches to Page settings with a Label, which replaces the positional name in the tab, the canvas divider, and the respondent’s step indicator, and a Visibility condition builder. When a page’s rule is false the whole page is skipped: the respondent never sees it, and its fields are not required. This works for every page, including the first.

Duplicate a page. Select its tab and click duplicate. The page and every field on it are copied in below, with fresh field names, and any visibility rules on the copies are rewritten to point at the copied fields rather than the originals. A named page’s copy is named <name> (copy).

Delete a page. Select its tab and click delete. Because deleting a page also deletes its fields, this confirms first and counts them: Delete Page 2 and its 6 fields? Choose Delete page, or Keep page (or press Escape) to back out. Undo appears in the snackbar afterwards, and Cmd/Ctrl+Z works too. The last remaining page cannot be deleted.

Move fields between pages. Switch to All pages and drag the field from one page’s sheet onto another. Nothing can be dropped above the first page divider: a form always starts on page 1.

Sections, columns, and repeating groups

Sections

A Section groups fields under a heading. It is a real group, not a visual divider: a visibility rule on a section hides everything inside it, and the fields within one are wrapped in a bordered group with the heading on top, styled from your theme.

A section can also be collapsible. Select the section marker and, in Section settings, tick:

• Collapsible: respondents can fold and unfold the section.
• Start collapsed: it arrives closed. This option appears only once Collapsible is ticked.

Give the section a label before making it collapsible. The show and hide control takes its name from the label, so an unlabelled collapsible section leaves anyone using a screen reader with a button their software cannot announce. The builder asks you for a label first.

Collapsing is presentation, never visibility. A collapsed section’s fields still count: answers stay in the submission, rules still evaluate, and a required field inside a collapsed section still blocks submit. If you want a section to genuinely disappear for some respondents, give it a visibility rule instead.

Columns

A Columns block lays fields out side by side, with a Column Break separating one column from the next and an End Row marker closing the block. Fields inside a columns row whose rule is false are dimmed on the canvas, matching what respondents see.

Repeating groups

A Repeating Group collects a set of answers more than once: line items, attendees, assets, addresses. Respondents add and remove rows, and each row creates a child record against the object you mapped its fields to.

Repeating groups render everything you can put inside one, including columns, description text, and hidden values in every row. They can also be nested: inner rows create their child records under the right parent, so a form can capture, for example, sites and then the assets at each site.

Visibility rules

Select a field and open Visibility in the inspector to build a rule.

1. Choose whether the rule requires all or any of its condition rows to match.
2. Each numbered row picks a Field, an Operator, and a Value.
3. Add or remove rows as needed. The field stays hidden from respondents until its rule is satisfied.

Operators: equals, does not equal, contains, greater than, at least, less than, at most, is blank, is not blank.

Values offer real choices rather than free text wherever the product knows them. Checkbox fields offer Checked and Unchecked; Picklist and Radio fields offer that field’s own options.

Under the conditions, the rule reads back in plain English: Shown when Multi-Select 1 contains “sports”. An Advanced toggle reveals the raw expression when you want it.

Three behaviours are worth knowing:

• “Is blank” means blank. An input typed into and then cleared, a whitespace-only answer, and an empty multi-select all count as blank.
• Rules that depend on each other settle correctly. A hidden question’s answer reads as blank to any rule that references it, so a follow-up question hides the moment the answer above it changes. What you see is what is reviewed, validated, and saved.
• Answers a respondent could not see never reach your records. They are stripped in the browser and again on the server, including per-row fields inside repeating groups. Hidden fields you set up deliberately, such as a Hidden Field carrying a campaign ID, still submit.

The Logic Map

Switch the top-bar view toggle from Canvas to Logic Map to see the whole form’s conditional logic at once:

• A dependency graph of which fields drive which.
• A plain-English list of every rule in the form.
• A simulation mode where you answer the driving fields and watch which dependent fields would show or stay hidden. Hidden ones are marked skipped in simulation.
• A Logic only filter that hides everything not involved in logic. A field survives the filter if it carries a rule of its own or some other field’s rule reads it, so both ends of every dependency stay visible.

Use it to check a form’s logic before publishing. It is the quickest way to find a rule that can never be satisfied, or a field that two different rules depend on.

Mapping fields to Salesforce

Each field can be mapped to a Salesforce Object.Field target.

1. Select a field on the canvas.
2. In the inspector, next to Salesforce mapping, click Map field.
3. Pick an object in the left column, then a field in the right column. Use the search boxes to filter long lists.

The picker stays inside the inspector panel, and long object and API names wrap rather than being clipped, so the list stays usable however deep your schema goes.

Review every mapping at once

Deselect everything on the canvas and use View field mappings under Data on the right rail. The Field mappings overview lists every mapped field in one place: label, type, its target chip, and a match badge on any field ticked for matching. Click a row to jump to that field’s settings.

Check this list before publishing. A field you meant to map and did not, or a match flag ticked by mistake, is easy to miss when reviewing fields one at a time and obvious in the overview. Publishing also warns you when fields are unmapped, telling you how many of how many.

Matching: update instead of duplicate

Tick Use for matching on one or more mapped fields and a submission’s write becomes an upsert rather than a plain insert.

All ticked fields on the same object are ANDed together as the match key. A submission must agree on every one of them to update an existing record. Otherwise it inserts a new one.

A few rules that follow from that:

• A weak key matches the wrong record. Last Name on its own will match many records, so use a key that identifies one person or account, such as Email plus Last Name.
• An incomplete key inserts. If a submission leaves any ticked field unanswered, the key is treated as incomplete and that submission inserts rather than matching on the answered subset.
• Blank answers are skipped at processing. A blank answer never blanks a field on a record the submission matched. To clear a field on the target record, clear it on the record.

Check the match key before you publish. Deselect everything on the canvas and open View field mappings: the match badges show your key in one list. A field you meant to tick and did not, or one ticked by mistake, is easy to miss field by field and obvious in the overview.

Record types

If a form maps to an object with more than one active record type, open Settings in the top bar and find the Record types section. It lists only objects where there is a real choice to make: an object with a single active record type never appears, because the platform default already handles it.

1. For each listed object, pick the record type from the dropdown.
2. An object left unchosen shows Not chosen, and publishing is blocked until you pick one. You can still save the rest of your settings: only Publish itself is gated.
3. The choice applies only to records this form creates. A submission that matches and updates an existing record keeps whatever record type that record already has. A form never retypes a record it did not create.

Form settings

Click the gear icon in the top bar. Form settings shows the form’s public ID (fixed, because links depend on it), the Form name and its Folder, and groups the rest:

Availability

• Share URL (optional): where you actually placed this form. See Sharing a form.
• Open from and Close at: an optional scheduled window.
• Close after this many responses: an optional response cap.

After submit

• Success message: what respondents see when they are done.
• Show a review step before submit: respondents get a summary of their answers with edit links before the final submit.
• Redirect after submit: an optional URL to send them to instead.

Notifications and integrations

• Notify these emails on every submission, comma separated.
• Send the respondent a confirmation email, chosen from the form’s Email-type fields, or Off.
• Webhook URL: receives a signed POST on every submission.

Notification and webhook sends both swallow their own failures by design, so a bad address or a down endpoint can never block a submission from being staged. This modal is the only place that validates them, so a malformed email address or a webhook URL that is not https:// is rejected here rather than failing silently later.

Record types

As described above.

Theme

The org-wide theme (brand colour, background, text colour, font family, corner radius, field spacing) lives under Setup, Custom Metadata Types, Forms Theme. Individual forms can override it, and the form header title comes from the theme and is rendered on served forms.

Accepting responses

The top bar carries a state pill reading Accepting responses or Not accepting responses. Click it to switch intake on or off. The change saves immediately, with no separate Save.

A form must be published before it can be switched on. Respondents are only ever served a published version, so switching intake on beforehand would put an unfinished draft in front of them. If you try, the builder refuses and tells you to publish first. This is rarely something you meet in practice, because publishing a form for the first time switches it on for you.

What a respondent gets follows from the state:

The last row is deliberate. Saying “closed” about a form that was never published would confirm, to anyone guessing URLs, that the form exists. An unpublished form stays invisible instead.

A closed form says so consistently: a respondent who had the page open before you closed it, and submits afterwards, is told the form is closed rather than that it does not exist. A closed form, or one that has hit its response cap, also refuses file uploads, so a respondent cannot leave files behind for a submission that will not be accepted.

Scheduled windows and response caps produce their own notices: This form is not open yet, This form is no longer accepting responses, and This form has reached its response limit.

The dashboard shows this state as a read-only Accepting or Paused badge. The builder is where you change it.

For public forms: a closed form only reads as closed if the site’s guest sharing rule still shares it. That rule needs both criteria. See Guest access.

Sharing a form

With nothing selected on the canvas, the right rail’s Share tab shows the form’s public link. The link is resolved, never guessed, in this order, stopping at the first hit:

1. The form’s own Share URL, from Form settings, Availability. Paste the address where you actually placed the form. This is the answer for a form on a hand-built Experience Cloud page, embedded on a customer’s own site, or anywhere else only you know about.
2. The org-wide public base URL from the Admin Dashboard, used as a template, with {form} replaced by this form’s external ID.
3. Nothing.

When a link resolves you get the URL plus Copy link, Show QR, Download blueprint, and Open as test respondent, which fills in the live form without counting toward results, caps, or experiments.

Prefill links start a respondent off with answers already filled in from a record. Pick the record by searching for it by name: the search is scoped to the objects the form maps to, so you do not need to paste a record ID. A form that maps no fields says so rather than offering a picker that could not work, and a form that has not been published yet tells you to publish it first, because a prefill link against an unpublished form returns nothing.

When nothing resolves, the panel says so and offers Download blueprint and nothing else: no link, no QR code.

This is intentional. A form can be placed anywhere, so there is no address the org can derive for every case, and showing an incorrect link is worse than showing none. That is particularly true of a QR code, which is often printed before anyone tests it.

Publishing, versions, and A/B experiments

Publishing snapshots the current draft into an immutable version that respondents see. Your draft keeps evolving independently until you publish again.

1. Click Publish in the top bar.
   • If there are things worth knowing first, a Before you publish dialog lists them, under the heading Nothing here blocks publishing: these are things respondents or your team will notice. Choose Keep editing or Publish anyway. Typical warnings: a required choice field with no option source, a mapped File Upload, and fields left unmapped.
   • Three things hard-block and cannot be overridden: a running experiment (end it first), visibility logic that cannot settle, and an unresolved required record type.
2. On success you get a short confirmation: Published, This version is live, with a single Done button. It deliberately carries no link, because where a form can be reached has more than one answer. That lives in the Share tab.
3. Publishing a form that is paused turns intake on. If a form has never been published and is not currently accepting responses, its first publish also starts it accepting, and the confirmation says so. Republishing never re-opens a form you deliberately closed, and restoring an old version never re-opens one either.
4. Once published, the Versions tab on the right rail lists every published version with Changes (a diff against the previous version) and Restore (replaces the current draft with that version’s fields, without affecting what is published). Draft changes since published diffs your in-progress draft against the live version. Any edit that moves the draft away from the live version, including deleting a field, marks the form as edited on the dashboard, so you can see at a glance which forms have unpublished work.
5. To A/B test a change, click Test vs live on any prior version’s row to start a 50/50 experiment against the currently published champion. Set an Experiment split percentage first if you do not want an even split.
6. While an experiment runs, a banner shows live counts and a significance readout, with Promote challenger (make it the new published version) and Keep champion (end the experiment and discard the challenger’s traffic share).

Working with responses

The Sliick Responses tab is the working surface for staged submissions. Open it from the app, or from a form’s Submissions row action on the dashboard.

Filter with the status picker (All statuses, Received, Processing, Completed, Failed), the form picker, a from and to date range, and an Include test checkbox. Test-respondent submissions are hidden until you tick it. There is no free-text search here: searching happens on the dashboard, across forms rather than responses.

Preview what processing will do

Click the row. The panel that opens is a dry run, titled What processing would do. It shows every record processing would touch: Create, Update existing, or Create child row, the object, the field values it would write, and, where the form has matching fields, whether this submission matches an existing record or would insert a new one.

Nothing is written at this stage. Click the row again to close the panel. If the form maps no fields at all, the panel says so rather than showing an empty plan.

Any files a respondent uploaded are attached to the submission record as soon as it is received, so you can open them while reviewing, before you process anything.

Correct answers before processing

While a submission is Received or Failed, the panel header offers Edit answers. Change what needs changing and click Save correction. Back to preview returns without saving.

Corrections are an overlay. The originally submitted answers are preserved unchanged and stay auditable, and processing reads the corrected values. Saving a correction on a Failed submission puts it back to Received, ready to retry.

Remember that blank answers are skipped at processing, so clearing a value here will not blank that field on a record the submission matches.

Process, retry, and export

• Each row carries one action: Process while it is Received, Retry once it has Failed.
• Tick several rows and use Process Selected to run them together. Afterwards a summary line reports n of m processed successfully.
• Export CSV downloads every submission matching your current filters, including status, form, date range and Include test, across all pages rather than just the page on screen. Each row carries the answers as a JSON cell and an IsTest column, so test-respondent rows stay identifiable once you include them. The export stops at 2000 rows without saying so, while the count above the table keeps showing the true total. If those two numbers disagree, narrow the date range and export in slices.
• Processing runs as you, in your permissions. If you cannot create or edit the target records, processing fails with that error rather than escalating.

Processing does more than staging: it maps staged answers onto target records via each field’s mapping, upserts against the match key where one is configured, applies the form’s record-type choice on newly created records, links uploaded files, and creates repeating-group child rows.

Results, funnels, and NPS

With a specific form selected in the form filter, View results opens a per-question summary of the answers received: distributions for choice fields, minimum, average, and maximum for numeric ones, and counts with samples for text. Alongside it sits the Views, Starts, Completions funnel.

The funnel only carries numbers where view and start tracking is available for the page the form is on. Where it is not, the panel says so and the rest of the results still work.

The Survey pulse (NPS) picker summarises any form carrying an nps_score field on the 0 to 10 scale, splitting promoters, passives, and detractors. The NPS survey starter creates that field for you.

Public forms on Experience Cloud

The package includes a subscriber-facing component, Sliick Experience Form, that renders forms on Experience Cloud pages.

Place the component

1. Open Experience Builder for the target site.
2. Navigate to the page where the form should appear.
3. Drag Sliick Experience Form from the component palette onto the page.
4. Set Form External ID to the target form’s external ID.
5. Optionally configure Source Channel, Submit Button Label, and Success Message.
6. Publish the site.

One page can serve every form

Leave Form External ID blank and the component reads the form’s external ID from the page URL’s ?form= parameter instead. Pair that page with an org-wide base URL of https://<your site>/forms/f?form={form} on the Admin Dashboard, and every form in the org gets a working share link without another page being built.

Set the property when a page is meant to serve exactly one form. Leave it blank for the shared page.

The hidden field on public forms

Public forms include a hidden field that respondents never see. A script that fills in every input on the page will fill this one too, and a submission that arrives with it completed is discarded: the sender gets an ordinary-looking confirmation and nothing is recorded. There is nothing to configure.

This catches indiscriminate form-filling bots without putting a CAPTCHA in front of real respondents. It is not a general spam filter, and it does not stop a script written deliberately against your form. There is also no rate limiting in the package, so a form that attracts sustained automated traffic needs a control in front of it rather than inside it.

The site itself must be public

An Experience site does not serve pages to guests until it is both published and available to guests. Publishing alone is not enough:

• Experience Builder, Settings, General, Public Access must be on. With it off, a guest hitting the page is redirected to the login screen or gets a Page Not Found, even though the guest API routes keep answering normally.
• The site must be Live under Administration, Settings, Activate, not Under Construction.
• Custom pages are served under /s/, so the address is https://<domain>/<prefix>/s/<page>.

Guest access for public forms

Public forms are served to your Experience site’s guest user, and that user needs access set up before a form will load. Salesforce does not allow a managed package to ship a site guest profile, so this part is yours to configure. There are four steps.

1. Assign the Submitter permission set to the guest user

Assign the packaged Sliick Forms Submitter permission set to the site guest user. That single assignment covers everything the package can grant: read access to form definitions and elements, visibility on the fields the runtime reads, and Apex class access to the one controller a public form needs.

A guest user can hold a permission set, and access granted that way works in guest context. If you want to see exactly what is in it, open the permission set in Setup rather than working from a list here, because the permission set is the definitive record and it moves with the package.

The symptom of a missing assignment is Unable to load form where the component is placed on an Experience page.

Do not grant a guest user access to the REST handler classes. A public form reaches Salesforce through the form component’s own session-protected connection, not through the package’s REST endpoints. Those endpoints are reserved for authenticated integrations, they are deliberately not on the Submitter permission set, and adding them to a guest profile would open your forms to anonymous callers.

2. Create the guest sharing rule

The permission set cannot do this part, and object access alone is not enough. With Secure Guest User Record Access enforced, which Salesforce mandates, the guest sees no form definition rows until a sharing rule grants them.

1. Setup, Sharing Settings.
2. Find Form Definition and click New under Guest User Sharing Rules.
3. Configure:
   • Rule type: Guest user access, based on criteria
   • Criteria, with filter logic 1 OR 2:
     1. Is Active equals True
     2. Was Published equals True
   • Share with: the site’s guest user
   • Access level: Read Only
4. Save.

Both criteria matter, and the second one is easy to skip. A form that has been published and then had intake switched off must stay shared. Otherwise the guest cannot reach the record at all, and respondents are told the form does not exist when they should be told it is closed. A form that has never been published and is not active matches neither criterion and stays unshared, which is intentional: a guest should not be able to confirm that such a form exists by guessing its URL.

Was Published is set the first time a form is published and is never cleared, so criterion 2 means “this form has been live at some point”.

Form Element needs no rule of its own: it is controlled by its parent and inherits this grant.

If a form reads as missing, fix the sharing rule rather than widening the guest profile. Sharing criteria are evaluated in system context and the package reads the relevant fields in system mode, so neither consults the guest’s field permissions. Adding field access changes nothing except the guest’s surface area.

3. Make the site public and live

An Experience site does not serve pages to guests until it is both published and available to guests:

• Experience Builder, Settings, General, Public Access must be on. With it off, a guest hitting the page is redirected to the login screen or gets a Page Not Found, even though the API routes keep answering normally.
• The site must be Live under Administration, Settings, Activate, not Under Construction.
• Custom pages are served under /s/, so the address is https://<domain>/<prefix>/s/<page>.

4. Network settings

If your Experience site uses a custom domain, or you have tightened CSP or trusted-site settings, confirm the form page still loads for an anonymous visitor after publishing.

Why guests never get access to submission records

You may notice that no packaged permission set grants access to the submission object, and that you should not add it.

Every guest visitor shares one Salesforce identity, and that identity would own every staged row. Read access on submissions would therefore let any visitor read every other visitor’s answers.

Instead, the guest publishes a submission platform event, and the package inserts the submission record itself in automated process context. The guest never touches the object, and is never told the ID of the record its submission created.

Guest setup checklist

• Experience site exists, is published, is Live, and has Public Access on
• Sliick Forms Submitter assigned to the site guest user
• Guest sharing rule on Form Definition, Read Only, filter logic 1 OR 2 on Is Active and Was Published
• Smoke test: open the form page in a private browser window, with no Salesforce session, and submit it
• The submission appears in Sliick Responses

Blueprints, ALM, and moving forms between orgs

A blueprint is the portable JSON for a form: its definition, its elements in order, and their configuration, keyed by external IDs so it round-trips cleanly between orgs.

Export

1. Open the form in the Form Builder.
2. With nothing selected on the canvas, open the Share tab.
3. Click Download blueprint.
4. Store the file in version control, or hand it to the destination org’s admin.

Every export declares the format it was written in, so a file declaring a version newer than the installed package understands is refused rather than guessed at. If you see that, the file came from an org running a newer version of Sliick Forms than this one.

Import

1. Go to the Sliick Admin Dashboard.
2. Click Import blueprint in the Forms toolbar and choose the .json file.
3. Review the summary: definitions created, definitions updated, elements created, elements updated, elements deleted.

Import is desired-state, not additive. If the incoming blueprint omits an element that still exists in the target definition, that element is deleted. Read the delete count.

Import also refuses a blueprint whose structure a form could not actually render, naming the blocks involved and writing nothing at all. Two examples: a page or section that opens inside a repeating group, and an End Repeat that closes nothing. Rearranging such a file to make it fit would move fields out of the repeating group they were authored in without telling you, so the import refuses instead. Because nothing partial is written, you can fix the file at source and re-run.

Recommended ALM rules

1. Keep definition and element external ID values stable across environments.
2. Never use Salesforce record IDs in a deployment workflow.
3. Export from a known-good source org before making large edits elsewhere.
4. Review delete counts carefully after each import.
5. Keep blueprint JSON in git, so form changes are auditable outside the org.

Retiring or deleting a form

Neither the dashboard nor the builder offers a delete-form action, and that is deliberate. Retiring a form is almost always a matter of switching Accepting responses off, which keeps the form, its versions, and its responses intact while telling respondents it is closed.

To remove a form outright, delete the Form Definition record from the object’s list view. Its elements and published versions are master-detail children and go with it. Staged submissions are not deleted: their link to the form is cleared, so the response data survives the form.

Export a blueprint first if there is any chance you will want the form back.

Troubleshooting

Getting help

Everything in this guide works today in production orgs. What is still open is the scope of 1.0: which remaining gaps matter most, and which capabilities orgs running intake need next. Your feedback decides that.

• Install Sliick Forms free from the AppExchange.
• Email support@Sliick.com with bugs, rough edges, a field type you need, or a workflow the builder does not fit. Every message is read by the people who build the product.
• Sliick Forms product page for the overview and install link.
• Book a walkthrough if you would prefer a demonstration.

To help us act on a report quickly:

• For a bug, include the form’s external ID, whether the form is public or internal, and what you expected to happen.
• For a feature request, describe the task you are trying to complete, not only the feature you have in mind.