At the end of an iteration, it's not required to release a software product. Scrum calls this an Increment, and other methodologies may have different names. The purpose is the same - at the end of your iteration, have something that is in a state that could be delivered to a customer or user.
I can't speak to the specifics of Service Now (and this community does not provide support for specific products or tools), but what you want should be achievable. I currently use Jira, so I can describe our flow there.
Backlog items start in Open. When a developer cuts a branch (for a code change) or starts working on an item (for something that isn't code), the ticket is moved to In Progress. When the work is being reviewed, it goes to Under Review. Once the development team says it's done, it goes to QA Review (I work in a regulated industry, so we need independent test of all work) and then Ready for Release. It stays there until the release is done, at which point things are moved to Released and then fall off the board. Any item that is in the "Ready for Release" is considered done and counts toward our burn down.
I would recommend consulting the support channels for your tool. My recommendation would be to have a "Done" column that indicates that your work is done, however you define it, and is ready to release. Then, be able to put the item into a "Released" state, at which point it falls off the board. Ideally, things that are Done would count toward items completed in your sprint, but you'd also want them to stay on the board until they are actually released and the release team can move them to the Released state. Filters can show/hide these from the development team, if necessary.
If the tool that you have doesn't support your process, then you have decisions to make. In my opinion, tools (especially expensive ones) should conform to the way that you work. However, you may not be able to simply change the tool and you don't want to fight the tool - it'll only make doing your job harder. So you need to evaluate the workflows that the tool gives you and see if there's something comparable. Perhaps small changes to your process, maybe in conjunction with configuration changes to the tools, can bring you to something that works well.