How to Update a Public UI Page to Prevent Sessions from Being Created

[cmitchell2323]

Hello Everyone, My organization currently has a public UI page that is available to anyone on the Internet. The current workflow for this form is an external or internal user from our organization will navigate to the URL, fill out the form, attach any necessary files, and then submit the form to ServiceNow, leading to a record being created. This entire workflow involves a service account session being created on the back-end in order to handle the submit and attach operations. I have been tasked with trying to come up with a solution that would eliminate the need for a service account session to be created. Has anyone ever dealt with this situation and if so, what is the best way to handle it? Here is what I have thought of so far:

• Thought about creating specific ACLs for the "guest" user account so that it has the ability to perform the attach and submit operations

I am also completely open to other ideas outside of a UI page entirely. My manager is completely open to the idea of re-doing the form somewhere else in the Platform if that is the more efficient approach to meet our business need. Thank you to everyone in advance, I appreciate the help!

[Menka1]

I would suggest instead of a custom UI Page + Scripted REST API running under a service account, move the form into the Service Catalog as a Record Producer (or a Catalog Item with a Record Producer behind it) and set Available for: Guest in its catalog access settings.

Why this works:

• ServiceNow already has a built-in, supported pattern for letting anonymous ("guest") users submit catalog requests — it's not something we're bolting on ourselves.
• Access is scoped to the catalog item and its variables, not a wide-open table ACL. That's a much smaller, easier-to-review permission grant than giving the guest role blanket create/write access on the target table.
• File uploads use the catalog's native attachment variable type, so we're not manually granting guest write access to sys_attachment — it's handled through the same scoped catalog permission model.
• No service account, no login/session setup, no OAuth token juggling on the back end. The record gets created the same way any other catalog request does.

What we'd still need to configure:

• Enable the guest role on the specific catalog item (not the underlying table broadly).
• Add basic anti-abuse guardrails ServiceNow supports out of the box — think CAPTCHA/rate limiting on the portal widget, and a Catalog UI Policy or Catalog Client Script to validate required fields before submit.
• Confirm with Security Architecture that this scoped, catalog-level guest access (vs. a raw table-level ACL) meets least-privilege expectations — this framing should make that conversation much easier than the original ACL idea.

[cmitchell2323]

Good Morning @Menka1, thank you so much for the information! I did have one follow-up question for you. How exactly would this work if our Service Portal requires authentication to get to the landing page? I understand having the catalog item/record producer being available to guest, but how would the user be able to get to that catalog item if they need to authenticate to get to the Service Portal/Employee Center?