All posts

How to Build a ServiceNow Portfolio When You Have No Work Experience

I had certifications and real ServiceNow projects, but no years of commercial ServiceNow experience. Here is how I learned to turn one project into credible portfolio and interview proof.

I remember leaving interviews knowing I could have explained myself better.

That feeling is difficult to describe unless you have experienced it.

You know the project. You built it. You remember the hours spent inside your Personal Developer Instance figuring out why a flow did not fire, why a user could see a record they should not see, or why a data pill was not returning what you expected.

Then somebody asks a simple question:

“Tell me about a ServiceNow project you built.”

And suddenly your brain tries to retrieve the entire project at once.

You start with Flow Designer. Then jump to ACLs. Then remember the catalog item. Then go backwards to the business problem. Somewhere in the middle, the answer becomes longer but somehow less clear.

I have been there.

What made it frustrating was that the issue was not always that I lacked the knowledge. Sometimes I simply had not learned how to turn what I knew into convincing evidence.

That realization changed how I started thinking about a ServiceNow portfolio.

I was trying to break into ServiceNow without years of commercial ServiceNow experience

I was not starting from zero in technology. I had already spent years building for the web and working in UI and UX. But ServiceNow was a different arena, and recruiters were not going to treat unrelated technical experience as if it were years of hands-on ServiceNow delivery.

I had certifications. I had completed structured learning. I had spent serious time in the platform. I had built applications.

Still, job descriptions kept asking for the thing I did not yet have: professional ServiceNow experience.

It creates a frustrating loop for a lot of people entering the ecosystem:

You need experience to get the job. You need the job to get experience.

For a while, the obvious response seemed to be more learning. Another course. Another badge. Another certification. More notes. More platform features.

Learning mattered, and the certifications mattered. But eventually I had to admit something to myself:

Another certificate was not going to explain my technical decisions for me.

The gap I could influence was not “How do I magically get three years of experience?”

It was: “How do I create credible evidence of what I can already do?”

That is where the portfolio became useful

Not as a gallery.

Not as a collection of screenshots.

And definitely not as a place to make a personal project look like paid client work.

I started to see a portfolio as proof of thinking.

Can I take a business problem and turn it into a ServiceNow solution? Can I explain the lifecycle? Can I justify the data model? Can I secure the records? Can I test the experience as different users? Can I talk about what failed and what I changed?

Those questions are much more useful than “How many features can I fit into one PDI project?”

The project that changed how I thought about proof

One of the projects I built was EquipFlow, an employee equipment request and allocation application.

The idea was simple enough to explain without pretending it was revolutionary.

An employee needs equipment. They submit a request. A manager approves it. IT fulfills the work. An asset is assigned. The employee can see what has been allocated to them.

That simple lifecycle gave me room to work with Service Catalog, Flow Designer, approvals, Catalog Tasks, assets, a custom Equipment Allocation table, roles, ACLs and persona testing.

At first, I thought the impressive part was the list of ServiceNow capabilities.

It was not.

The interesting part was everything the project forced me to decide.

Why have a separate allocation record?

The Requested Item captures the request lifecycle. But the employee-to-asset relationship can live beyond the request. I wanted those two concepts to be trackable independently.

That decision gave me something to defend.

Why use an approval before fulfilment?

Because the business process required a manager decision before IT invested time assigning equipment.

That gave me something to explain about process design.

Why use ACLs?

Because an employee should be able to view their own allocation without automatically gaining visibility into every other employee’s record.

That gave me something to prove with impersonation testing.

This was the shift for me: a project becomes more valuable when every major component has a reason for being there.

Start with the business problem, not the feature

If you are building your first portfolio project, I would resist starting with “I need a project that uses Flow Designer.”

Start with a problem that somebody might genuinely have.

Employees need equipment. New hires need coordinated onboarding. Training requests are disappearing in email. Knowledge articles need review before publication. A support team needs a better follow-up process after poor customer feedback.

Once the problem is clear, the platform features become tools instead of decorations.

If you do not yet know what to build, I put together 7 ServiceNow project ideas for beginners and what each one can prove.

Choose one. You do not need all seven.

Build the entire lifecycle

A form that saves a record is technically a project. But it does not give you much to discuss.

The learning gets richer when something happens after the record is created.

A user submits something. A decision is made. Work is assigned. Data changes. Somebody gets notified. Somebody should be blocked from seeing something. A rejection path exists. An exception needs handling.

For EquipFlow, I could follow one story from beginning to end:

Employee request → Manager approval → IT fulfilment → Asset assignment → Allocation record → Employee visibility

That lifecycle gave me a much stronger portfolio story because I could explain how the pieces depended on each other.

Document the “why” while you are building

This is something I wish more beginners did from day one.

Do not wait until the project is finished and then try to reconstruct every decision from memory.

Keep a small decision log while you build. It can be a plain document. Nothing fancy.

  • Why did I create this table?
  • Why is this a reference field instead of a string?
  • Why does this approval happen at this point?
  • Why did I choose a Flow instead of another automation option?
  • Why does this user have this role?
  • What broke while I was building this?
  • What did I change after testing?

    • Those notes become some of the best material for your portfolio and interview preparation because they capture the thinking behind the configuration.

    Testing was where the project became believable

    When you build something yourself, you already know how you expect it to behave. That makes it easy to unconsciously test only the happy path.

    I learned to deliberately change perspective.

    Impersonate the employee.

    Impersonate the manager.

    Impersonate the fulfiller.

    Try to open a record you should not be able to see. Reject the request. Leave something incomplete. Ask what should happen when the path changes.

    The difference in how you talk about the project is huge.

    “I created ACLs.”

    versus

    “I impersonated an employee and verified they could view their own allocation record but could not access another employee’s allocation.”

    The first sentence names a feature. The second gives evidence.

    The seven things I would put on a ServiceNow portfolio page

    If I were documenting one project today, I would make sure the page answers seven questions:

  • What business problem was I solving?
  • Who were the users or personas?
  • What was the complete lifecycle?
  • What were the important technical decisions?
  • How did I handle roles, visibility and security?
  • How did I test the solution?
  • What failed, what did I learn, and what would I improve?

    • Your screenshots should prove something too

    A common portfolio mistake is uploading twenty screenshots because every screen feels important when you built it yourself.

    Most of them are not important to the reader.

    I would rather show four screenshots with a reason behind each one:

  • The request experience — to show how the process starts.
  • The Flow Designer lifecycle — to show how the process is automated.
  • The security or role configuration — to support your access-control explanation.
  • The final employee or fulfiller experience — to show the outcome.

    • The screenshot is not the evidence by itself. The explanation beside it is what makes it useful.

    Be honest about what the project is

    If the project was built in your Personal Developer Instance, call it a personal project.

    You do not have to make it sound like a production implementation for a company.

    Something as simple as “ServiceNow Personal Project — Equipment Request & Asset Allocation Application” is enough.

    Then explain the scope and the skills honestly.

    Credibility comes from being able to go deep when someone asks a question. It does not come from making the project sound more commercial than it was.

    The part I underestimated was not building. It was explaining.

    This is the part that became personal for me.

    I had interviews where I became tense. I rambled. I blanked on explanations I knew I understood outside the interview.

    Afterward, I would replay the conversation and think, “Why did I not just explain it like this?”

    That experience forced me to separate two skills that I had previously treated as one:

    Knowing the project is one skill. Explaining the project under pressure is another.

    The solution was not to memorize a perfect speech. It was to practice retrieving the structure of the project: the problem, my approach, the important components, the decisions, the test evidence and the outcome.

    I wrote a separate guide on exactly that: How to Explain a ServiceNow Project in an Interview Without Rambling.

    Once I started treating explanation as something that needed practice, the portfolio made more sense.

    It was not just a page for recruiters to browse. It was also a tool for helping me organize my own thinking.

    If I were starting again, this is the 30-day plan I would use

    Week 1 — Choose the problem and define the lifecycle

  • Write the business problem in plain English.
  • Identify the users and personas.
  • Map the process from trigger to outcome.
  • Decide the smallest useful scope you can finish.

    • Week 2 — Build the core solution

  • Create the request, tables and relationships you actually need.
  • Build the main automation.
  • Add approvals, tasks and notifications only where the process requires them.
  • Keep notes on the decisions you make.

    • Week 3 — Secure it and break it

  • Create the roles and ACLs.
  • Impersonate each persona.
  • Test the happy path, rejection path and obvious edge cases.
  • Capture evidence when something works — and when you fix something that did not.

    • Week 4 — Turn the build into proof

  • Create a simple lifecycle diagram.
  • Choose a handful of screenshots with clear captions.
  • Write the seven portfolio answers.
  • Record a three-minute demo.
  • Practice explaining the project in 60 seconds and then in deeper technical detail.
    • That is enough to create a real body of evidence without waiting for someone to give you permission to start.

    One project can change the conversation

    A personal project will not magically replace years of production experience. It should not.

    But it can change what you have available to talk about.

    Instead of saying only:

    “I am CSA and CAD certified.”

    you can say:

    “I built an equipment request and allocation application. Here was the business problem, here is why I separated the request from the allocation record, here is how the approval and fulfilment lifecycle worked, here is how I secured employee visibility, and here is how I tested it.”

    That is a very different conversation.

    The certification tells someone you learned. The project gives you an opportunity to show how you apply that learning.

    From project to proof

    Eventually, I realized this was the system I had been missing.

    Build something real enough to force decisions. Document those decisions. Test them. Capture evidence. Then practice communicating the story.

    That is also the problem I built ServiceNow Project Proof around. It is a practical playbook for turning one project into something you can present, defend and market — with EquipFlow as the worked technical blueprint.

    If that is the stage you are at right now, you can explore ServiceNow Project Proof.

    But even if you never use the playbook, I would leave you with this:

    Do not wait until somebody hires you before you start creating evidence of how you think.

    Build one project you understand deeply.

    Then learn how to prove it.