1) Assuming you are referring to Facilities Management; in some cases you can cause issues by customizing the form. For example if you removed the state field. That said, in most cases you should be OK, just will want to go into these areas before you make your changes to validate you are not removing a critical field.
Why is it that when you update the "Assigned to" field on the H/W (CI) form, it does not update the assignee Location on the "Asset" form. In other words it just update the "Assigned to" on the Asset form (FYI, there is an OOB client script for this)
What would you suggest if the requirement calls for having a "shelf location" within the stockroom must be known when selecting an item from a given stockroom...This is a twist to the requirement: (1) The item is a consumable asset (2) and due to some illogical reason, it may be housed/located on more the one shelf within a given stockroom.
I'm assuming you are referring to the "Location" field. There is a client script called "Set Loc/CC/Dep/Com from assigned to" which will set the location, department, etc. IF the field is defined/set for the assignee's (user in the sys_user table) record. So if it is not set when the Assigned To is set, it is probably because the Assigned user does not have a location set in their record.
Hi Eddie, yes I would agree with you. The 'Set Loc/CC/Dep/Com from assigned to' being an OnChange Client Script, will not run if the asset's assignee is changed via the configuration item.
Hi Eddie, As a general rule, it's best to discuss the requirement with the user and modify it into something that is logical. If you can't get them to create logical requirements than you will be stuck creating rules/scripts/etc. that will end up causing more harm then good in the long run. Then you will later end up with a "broken system" and the next requirement will be to "fix the system".
Hi Mary, just to add that as an admin you can easily locate the scripts that relate to a particular table using the Configure context menu on the relevant form. So you/your admin will be able to proceed with knowledge of the baseline scripts.
Can the coalesce script be developed to manage deltas on the records attributes? Specifically, when merging records - does the import set overwrite attribute values automatically or can that be handled on a field by field basis?
A customer on a recent Asset course in UK was living proof of Joel's point: her organization was making an effort to get 'back in the box' as a result of previous over-configuration.
Coalesce is a True/False field on the Transform Map. So if it is set to true and an incoming record "matches" then it will update any of the matching field values from the transform with the new data. If you need to run a script to determine Coalescence then you can do that by not using the OOB field, and instead rely entirely on a Before import script in the transform. This will be a lot more work though so make sure that you can't find a way to use the OOB coalesce field.
Hi Eddie, I just tried this in my dev instance and I was not experiencing the behavior you describe. For me the location and dept are being updated when I select a different assignee.
Has anyone had success or heard of success enabling Asset Managers to import and transform their own data, based on vendor spreadsheets or spreadsheets they created?
There is a degree of risk involved, so I wanted to see if anyone is actually doing this...
One possible reason is that the install status of the Asset is 2 (on order), 6 (in stock) , or 9 (in transit). If it is any of these then the script will not run to set these values. Apart from that it should be working as I am not able to reproduce the behavior assuming one of these states is not being used/set.
Is it better to create a transform map or do the asset import via the asset table or even the computer table? Currently I do the import directly to the table. Can you tell me what pros and cons are to either or?
We currently have an 'asset import form' module that strictly has 3 columns (asset tag, serial number, MAC address). It is already set that we can only import one specific model category, model name & state. It is super helpful importing new assets when they are received at our dock.
We are currently looking at ways to have the Asset Managers run imports to update assets in bulk (ie: retire, in stock)
Limited functionality, One table at a time, Coalesce on sys_id
Load and Transform
Pros
Robust, Coalescence options, Ability to clear fields, Ability to conditionally/dynamically update records, Control over reference data (insert/ignore)
Cons
Administrative overhead
I would probably only do a direct import from a data set that has been exported from ServiceNow, and most likely with a limited amount of records I can validate myself. Larger data sets are naturally a greater risk because it's not practical to validate thousands of records. Transform maps can help you protect your data by making decisions about what to do with unwanted updates.
Everything else is pretty manual after the fact. Our AM only captures asset tag, serial number, MAC address, location and who it is assigned to. We currently don't use Discovery or CMDB at the moment, which we are currently looking at options for integration to fill in the other information.
Hi Joyce, there is no specific alert that I am aware of, but you can see which records were ignored or rejected in transform history module, and can look at the related import logs.
You should be able to see some of this information in the transform history/transform log. That said, the data that is logged here is not usually very verbose. As such sometimes its necessary to add additional logging using the "log" object in conjunction with a transform script.
Hi Eddie, I commented on this already, but for some reason it did not appear - maybe a refresh issue, so this is my second attempt.
Firstly, I completely understand your point that sometimes saying NO is not an option even if you feel the requirement is one you would rather push back on.
My thought would be use the Stockroom Type field to represent a shelf, so that a shelf would be treated as a special kind of stockroom. For me this has the advantage of being a relatively minimal configuration, so you would not need to adjust the 'Source Request' dialog if you use the Service Catalog integration (you will see this today if you are not already familiar with it). I have attached a screenshot of the Stockroom Type field
My second thought would be to have a chat with some of the BBC (Big Brain Consultants) in the room during one of the breaks. It's good with these kind of requirements to hear a few people's opinions before proceeding. You could offer your hard-won break snack for the idea you like the best!
Hi Brian, quite a few Asset Managers I have met in a training context have expressed frustration about not having more control over the import sets at their organization, given that they are ultimately responsible for the quality of the data imported.I can sympathize with this; as the AM has 'skin in the game' surely he/she should look after the Asset Imports?On the other hand I expect the Foundation Data (what Kailey referred to yesterday in her discussion of reference fields, eg users, locations, departments etc) is always going to be the admin's responsibilty so I guess the AM is always going to need a tame admin to help with that.
Hi Eddie, sorry, to clarify (end of day/lack of tea ...). If I change the assigned to on the Asset then the OnChange client script mentioned above runs as normal and it uses getReference() to look up the assignee's location, dept, cost center. However if I change the assignee on the CI then the client script, being a client script on the asset form only, will not run.
A workaround for this would be to remove 'isLoading' from the if statement in the client script, with the effect that next time you load the asset form the same script will run and populate the fields as normal. (Though the downside is that the client script then runs on form load). Another workaround would be to have a business rule on the CI form that runs only if 'assigned to' changes and then updates the related asset fields. You could also of course write an OnChange script for the CI. So in summary I see the inconsistency you are pointing out. I suppose it illustrates that Client Scripts can sometimes be something of a 'false friend'.
Hi Eddie and Brian, just to mention I added a couple of comments to your posts from yesterday - I'm afraid I updated a non-refreshed version of this article so a couple of my comments did not come through yesterday.
Can rules be created that auto assign assets to a maintenance contract based on business logic? Such as, if the asset is in a certain location then its covered by X contract...
If we didn't want to manage the entire Contract Lifecycle, is it as simple as not selecting an approver on the contract when it is created? Or, are there some business rules or workflow we should disable?
Can the contract cost information be tied to incidents? For example, I have a contract with a vendor that charges me $50 per incident. Since the assets will be tied to the contract, can I relate the assets to the CI's on Incidents to see the cost of incidents for covered assets during a specified time period?
