Do 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
I'm baffled that this little issue has never cropped up for me until now, but I recently discovered a little annoyance in ServiceNow while iterating through an array. This issue had me going round in circles for hours, so hopefully by sharing my findings with our readers, I can spare some folks the frustration I felt.
First, I'll tell you a little story about how it happened to me, and then I'll tell you the explanation for this odd behavior. Read More
I recently found myself in a situation where I had to check if a given record (the 'current' object in my case) matched a filter associated with another record (a client script, in my case). If you find yourself needing to do something similar, it might help you to know about an undocumented Glide API called "GlideFilter".
GlideFilter takes two arguments:
- A glide record containing the record you'd like to check
- The query string (aka "encoded query") you'd like to check it against.
The first argument may be self-explanatory - it's a GlideRecord object containing a single record. Read More
The second argument, if you're not familiar with encoded queries, is a string of text that represents a query. If you've ever built a query in a condition builder, you've built an encoded query.