To kick off the GenevaGems series, we'll start simple. Since I appreciate clean interfaces, I was happy to find the new minimalist navigation favorites view.
FujiForty series concludes with a list of recommendations that will help you make the most of your ServiceNow technology partner offering.
We all love creating module links for our application, mostly because it's so easy. While it does make it easier to find what's important, it can quickly clutter the navigation list. Here's my solution to clean it up.
I spent the past year dedicated to working with ISVs building apps on Fuji EA and GA releases. I realized that I have a pretty consistent and structured checklist that I follow for building and reviewing applications, although it's all been an auto-pilot process in my head. Some may say I’m giving out my secrets, but since CAVUCode is all about empowering vendors so they can manage their own applications, I’ll share my process.
There was a recent question on my first Form Charts post regarding advanced conditions. Since it's not really documented I did some experimenting.
In the last example I used a simple report filter. Show the "All Incidents by Category" report where the incident location is equal to the current form's incident location. Using this form chart interface limits you to a direct field mapping (location = current.location).
If you require a more advanced condition such as an OR condition you'll have to jump over to the "Advanced condition extension".
Anyone developing applications for the ServiceNow Store should have an understanding of how and when customers upgrade to the latest release. It's one of the first questions I get from the vendors I've been working with.
After the initial frustration with a locked down and undocumented Fuji scripted processor API I avoided them as much as possible. But sometime you just can't avoid them. I recently had a need to build a REST-like integration because the client app couldn't use SOAP, so scripted web services weren't an option. Since scripted REST services don't exist...yet, I needed to use a scripted processor to capture a POST request with JSON and return a JSON payload.
Most of the FujiForty series so far has been focused on the benefits and challenges of scoped applications and the related API changes. By far, the biggest reason to understand and work with scoped applications is so you can publish them in the ServiceNow Store. If you're not interested in publishing a particular application or utility in the store building a scoped app can be overkill and possibly add unnecessary extra development time. These are the times when you should just build a global application.
I've mentioned the marketplace or store in plenty of earlier posts. Yesterday during the Knowledge15 conference the ServiceNow Store was officially launched. CAVUCode was involved in launching two certified application which are now available in the store. Here's a run through of what it takes to get an application into the store.
Whether end users or QA engineers believe it or not all developers perform tests on their code. Sometimes it might not be as accurate or detailed as it should be, and sometimes it's not even documented. A developer knows the use cases they are coding for and can be sure to test for those cases. Handing an app over to QA may not always include a list of the tests performed or the expected results. This somehow needs to be captured by the product manager and/or the developer depending on the organization structure.