Week 5 was when everything from the previous month stopped being separate topics and became one project: Strawberry sFone, a fictional phone service that needed a working ServiceNow Instance - Incident Management, Groups and Roles, Service Catalog fulfillment, Workflow automation, Knowledge Management, Notifications, and Reporting- all connected.
That's what made this different from every earlier lab: nothing was isolated. Break one piece, and it shows up somewhere else. For the first time, I wasn't just following steps - I was troubleshooting like an actual administrator.
Using Form Builder, I added a new string field to the Incident record and expanded the Category dropdown with a new option - no scripting required. Then I tested it end to end: the field showed, the new category was selectable, data saved correctly, and the change carried through to the default view. Small task, but a good reminder that most "customization" In ServiceNow is really just careful configuration.
With Task 2 I built a child group under Service Desk, assigned it the [itil] role, and added five users. Then came the part that made me stop: when creating an account for one of the users, the default form had no Manager field. Instead of working around it, I opened Form Builder and added the field myself, right above Department, then created the user and confirmed the right manager was set.
Small moment, but It's the job in miniature: the platform doesn't always ship with exactly what you need, and part of being an admin is knowing you're allowed to fix that.
This task was the meatiest of the Capstone, and It's the one I learned the most from, not because of what I built, but because of what broke.
First, I had to get the Strawberry sFone catalog Item Into my Instance, which meant importing an Update Set ( All > System Update Sets > Retrieved Update Sets > Import Update Set from XML), previewing it, and committing it.
Then, in Workflow Studio, I built Strawberry Workflow - an automation with two paths. On approval, the request moves through three Catalog Tasks in sequence: Procurement orders the phone, Software configures the phone, and the Service Desk delivers it. On rejection, the request is marked rejected, the requester gets an email, and the flow ends.
Here's where it got interesting: I impersonated a user, David Loo, and submitted a request. Then I switched to his manager, Bud Richman, to test the approval - and the approval wasn't there. Nothing to approve, nowhere to be found.
My first Instinct was to assume the workflow itself was broken. Instead, I went back through the configuration piece by piece and found the actual problem: I'd built the flow, but never attached it to the catalog Item under its Process Engine tab. The automation existed - it just had no Idea It was supposed to run.
Once I fixed that, the whole thing worked cleanly: David submitted the request, Bud saw and approved it, the fulfillment tasks were closed out one by one, and Flow Executions in Workflow Studio confirmed the run compelted start to finish
The lesson wasn't really about workflows - it was that testing Isn't does It work?" It's "If it doesn't, where does the trail actually lead?"
I set the IT Knowledge Base's publish flow to Knowledge - Instant Publish, skipping the usual review cycle, and created an sFone subcategory under Devices. Then I wrote two articles: one for requesters explaining how to order an sFone through the catalog, and one for fulfillers covering what they need to know to actually fill the request - and confirmed users with the itil role could see it.
This is where a handful of earlier lessons - Knowledge Management, User Criteria, Service Catalog, Self-Service- stopped being separate concepts and started being one working piece.
I created a Telephone Services service (Support Group: Service Desk) and a Strawberry sFone Service Offering under it (Support Group: Strawberry Support), so Incidents would land with the right team automatically instead of needing manual triage.
Then I built a notificationL any new Priority 1 Strawberry sFone Incident fires an email to Strawberry Support with when It opened, who opened It, and the short description. I tested It by creating a matching Incident and watched the email land In the Sytem Outbox.
Nobody has to remeber to flag a critical Incident to the right team - the platform does It the moment the conditions are met
Last piece: a pie chart, Active sFone Incidents by Priority, scheduled to land in Strawberry Support's inbox every Monday at 8:30 AM with a short personalized note attached. Instead of a report someone has to remember to go check, it just shows up.
By the end, Strawberry sFone had a real request-to-resolution lifecycle: a form to report It, a group to route It, a catalog Item to request It, a workflow to fulfill It, docs to explain It, a notification to flag It when It's urgent, and a report to track It - all connected, not standalone.
The Process Engine bug is still the moment that stuck with me most. Configuration is maybe half the job. The other half is knowing how to trace a broken result back to its actual cause instead of guessing - and knowing when to reach for Form Builder, Workflow Studio, or Notifications before ever reaching for a script.
The training labs are done. This is where I actually started using it.