The way approvals work in ServiceNow by default is that an email goes out, and the user can click a link in the email to approve or reject. That link is generated in the default approval notification template using ${mailto:mailto.approval}. Clicking the link that is generated in the approval email based on this template, will pop up another email on the user's computer.
However, this only works if they have their system configured to correctly handle mailto href links, and if they received the email using the same program they've configured to handle mailto links, and if they're not using webmail.
Definitely not ideal.
How can we improve this situation? As is the case with nearly every problem in life, the answer is CODE!
Our goal will be to give users a link that they can click to approve or reject a record, that doesn't use mailto, and that works no matter how they're viewing or sending email.
Join me after the break to see a detailed explanation of how it's done, and download an update set that'll let you deploy this functionality in your instance right now, for free!
Read moreWe've all been there. -- You've been wired in, hammering away on code, making great progress on several fronts, when all of a sudden you're gripped with dread. You check the sprocket menu at the top-right, cautiously hopeful... but as it loads, and recognition sets in, the reality of the situation crashes into you like a sack of pidgeons.
You forgot to select your update set.
At this point, it is perfectly reasonable to curl up into a ball and weep at the fact that you're going to have to sift through hundreds or even thousands of updates in the Default update set in your busy environment, picking out the ones that are yours and that are relevant to your current work, manually opening each record one at a time, and moving them to the correct update set.
But here's a better idea -- What if you could just tick the box next to each update, click a button, and dump them all into your current update set?
Join me after the break and not only will I show you how to do that, but I'll give you an update set that you can deploy to enable that functionality in a matter of minutes!
Read moreAs most ServiceNow users know, when you hover over the icon next to a reference field on a given form, you can see some details about the record that's being referenced.
Well, what if you want to customize what fields are shown in that pop-up reference view?
When a requirement came through to do just that in my instance, I was stumped for a good long while, chasing down some inaccurate/outdated documentation, but eventually I figured out the following process.
Join me after the jump to see how to modify this pop-up view.
Read moreBrace yourself. Geneva is coming.
Personally, I'm excited - I like new things. I've always been the early adopter. But I know that not everyone is as gung-ho for the future as I am, so I thought I'd share some tips and tricks on ServiceNow's "Geneva", and the new, drastically overhauled "UI 16" that will be the new place where most of us ServiceNow developers spend our daily 8-12 hours.
Note: This is part 1 of a 2-part series on ServiceNow's Geneva update. This part will focus on the interface, and stuff you're likely to run into on day 1, as well as basic stuff you'll need to know so you don't shoot yourself in the foot. A more in-depth exploration of the different process areas such as changes to Knowledge Management, Change Management, performance, security, and so on - is forthcoming. So subscribe, and stay tuned!
Join me after the jump, and learn what's new in Geneva from the perspective of an admin, a developer, and a user - from the browser-based IDE and the new way to elevate permissions in high security mode, to the basics of navigation in the new world... of Geneva.
Read moreDo you have multiple developers working in the same instance? If so, there's a good chance that on at least several occasions, one of them has "stolen" an update/record from another. I'll explain what I mean by way of an example:
- Developer A is working on a project that involves changing a script include.
- Developer B, working in parallel on a separate task, also changes the script include.
- The update sets are pushed. Depending on the order, at least one developer is likely to see results in production that they do not expect based on their development.
So, how can we prevent these kinds of conflicts/confusion?
What if we could alert a developer whenever they're viewing a record that is captured in another active update set, that does not belong to them--
Read more
