- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-24-2026 03:26 PM
I'm looking for guidance and best practice here from the ServiceNow community. My team supports SNOW operations in the company. often times, they receive a generic request to build Forms or Workflows in Service Now without providing clear requirements. This causes additional follow ups, and unnecessary meetings. We are thinking of creating an intake form for SNOW related enhancement and requests like Building Access Forms and building Workflows are the two common requests. The idea is to get the users in the habit of providing requirements based on a list of questions. Any idea if you have something like this implemented at your company or if you had similar issue and helped improve it? Thanks
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
a month ago
Tab 1: Basic Details & Governance
This tab defines the "Who, What, and Where" of the catalog item.
| Field | User Input / Description |
| Request Name | The formal name of the Catalog Item. |
| Request Type | New item, modification, or workflow change. |
| Business Justification | Why is this item being created? |
| Business Owner | Name/Email of the person who approves the logic. |
| Target Audience | Who is allowed to see/request this? (e.g., All Employees, HR only). |
| Catalog Category | Where should this live? (e.g., Hardware, Software, Facilities). |
| Search Keywords | Tags to help users find this via search. |
| Expected Volume | Estimated requests per month (helps with license/load planning). |
| Icon / Image | Description or file name for the portal thumbnail. |
Tab 2: Form Variables & Logic
This is the "technical blueprint" for the fields the user will fill out.
| Order | Label | Variable Type | Choices (if any) | Reference Table | Mandatory (Y/N) | Visibility | Default Value | Help Text / Instructions |
| 100 | Environment | Choice | Dev, Test, Prod | Y | Always visible | Select target env | ||
| 200 | Application | Reference | cmdb_ci_appl | Y | Always visible | Select application | ||
| 300 | Justification | Multi-line | N | Show if Prod selected | Explain the need | |||
| 400 | Attachment | File | Y | Always visible | Upload approval email | |||
| 500 |
Tab 3: Workflow, Approvals & SLA
This defines what happens "behind the scenes" after the user hits Submit.
| Requirement | Details / Specifics |
| Approvals Needed | List in order (e.g., 1. Manager, 2. Dept Head, 3. Security). |
| Rejection Logic | What happens if rejected? (Close ticket, notify user, or allow edit?). |
| Fulfillment Group | The specific team that will resolve the ticket. |
| Catalog Tasks | Task 1: [Description] -> [Group]; Task 2: [Description] -> [Group]. |
| Notifications | Who gets an email at: Submission, Approval, Completion, Rejection? |
| SLA Expectations | Resolution time (e.g., 2 Business Days). |
| Post-Flow Action | Does this update an asset record or the CMDB? |
This is just for your reference; you can update the Excel as per your needs.
Hope this helps! 😊 If it worked for you, please mark it as correct ✅ so others can benefit too.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-30-2026 06:02 AM
This is actually a pretty common challenge. The best way to handle it is by creating a structured “ServiceNow Enhancement Request” catalog item. It really helps reduce back-and-forth and makes things much easier for the dev team.
What usually works well is keeping the initial form simple, and then showing more specific questions based on what the user selects.
Basic structure
Start with a few common fields:
Request Type (New item, modify existing, workflow, etc.)
Business justification
Who will use it
Approx expected volume
For catalog item requests
Instead of asking users to type everything in free text, it’s much better to give them an Excel template for variables.
Ask them to fill things like:
Label
Type (text, reference, choice, etc.)
Choices (if applicable)
Mandatory (yes/no)
Help text
This saves a lot of time later when building the form.
For workflow/flow requests
Ask a few key things upfront:
Who should approve
Which group will work on it
What tasks should be created
Any notifications needed
SLA expectations
One important tip
The biggest challenge is getting users to actually follow this process. If someone sends a request over chat or email, just redirect them to this form. Once people get used to it, things become much smoother.
This approach is pretty standard and works well in most teams.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-30-2026 06:56 AM
Thank you this is very helpful. do you have an example of an excel template that you can share?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
a month ago
Tab 1: Basic Details & Governance
This tab defines the "Who, What, and Where" of the catalog item.
| Field | User Input / Description |
| Request Name | The formal name of the Catalog Item. |
| Request Type | New item, modification, or workflow change. |
| Business Justification | Why is this item being created? |
| Business Owner | Name/Email of the person who approves the logic. |
| Target Audience | Who is allowed to see/request this? (e.g., All Employees, HR only). |
| Catalog Category | Where should this live? (e.g., Hardware, Software, Facilities). |
| Search Keywords | Tags to help users find this via search. |
| Expected Volume | Estimated requests per month (helps with license/load planning). |
| Icon / Image | Description or file name for the portal thumbnail. |
Tab 2: Form Variables & Logic
This is the "technical blueprint" for the fields the user will fill out.
| Order | Label | Variable Type | Choices (if any) | Reference Table | Mandatory (Y/N) | Visibility | Default Value | Help Text / Instructions |
| 100 | Environment | Choice | Dev, Test, Prod | Y | Always visible | Select target env | ||
| 200 | Application | Reference | cmdb_ci_appl | Y | Always visible | Select application | ||
| 300 | Justification | Multi-line | N | Show if Prod selected | Explain the need | |||
| 400 | Attachment | File | Y | Always visible | Upload approval email | |||
| 500 |
Tab 3: Workflow, Approvals & SLA
This defines what happens "behind the scenes" after the user hits Submit.
| Requirement | Details / Specifics |
| Approvals Needed | List in order (e.g., 1. Manager, 2. Dept Head, 3. Security). |
| Rejection Logic | What happens if rejected? (Close ticket, notify user, or allow edit?). |
| Fulfillment Group | The specific team that will resolve the ticket. |
| Catalog Tasks | Task 1: [Description] -> [Group]; Task 2: [Description] -> [Group]. |
| Notifications | Who gets an email at: Submission, Approval, Completion, Rejection? |
| SLA Expectations | Resolution time (e.g., 2 Business Days). |
| Post-Flow Action | Does this update an asset record or the CMDB? |
This is just for your reference; you can update the Excel as per your needs.
Hope this helps! 😊 If it worked for you, please mark it as correct ✅ so others can benefit too.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
a month ago
Yes, thank you very much. I will review this with my team and ask follow up questions if any 🙂
