At its core - this is an allocation issue.
I want to allocate things from one table to another, and make the thing on the first table no longer available for allocation.
1 of 1 people found this helpful
How about linking the CI's to a user called stores initially, then in the process remove the CI chosen from that linkage which you can do via a process action. You can then link that item to the person, again via a process action. Anyone then looking at CIs allocated to stores will see this one has disappeared and has been allocated
Thanks for the answer. Could you humour me and describe in a little bit more detail how the process action would look?
Things to consider:
- Are these 'break link' actions OOTB actions? If so, what are they called, and is there anything else to configure?
- Are these actions that require a calculation? If so, is there a related article?
- On which collection would these actions be created?
- Are these windowed or windowless actions?
- Are these automatic or manual actions?
- If manual, do they connect to an automatic action window?
- Do you have a screenshot of something similar in your process lifecycle?
Thanks again for all of your help. I am still learning to walk the walk.
Sure - check out the LDSDDesigner manual. This feature of having a process action to link/unlink CIs and was introduced in 7.4 and in the 762 manual you'd be looking on page 170 onwards
I've spent the day trying to link CIs to a user using the process outlined in the manual.
- I've created my linking action on the Change Management -> Change object
- I've linked it to an automatic action in a simple process (seen in screenshot)
- In my automatic action, I try to tell it to link ALL CIs to a specific user (also seen in screenshot)
- I run the process, then check to see if the CIs have been linked, and they haven't. They simply don't show up.
The manual seems to think that CIs are somehow attached to a module (see 2nd screenshot) but I have no idea what that is about, since I import my CIs from Excel. They exist entirely on their own, independent of any module or other object.
As a guess it looks as though you are not using the standard LDSD CMDB, but pulling data into a process collection to hold data which is actually CMDB informartion. To be direct I'd suggest you talk to whoever designed that process for you (or LD if it's one of their processes). The reason I say that is that you really want to try and use the CMDB where you can as a lot of LDSD functionality uses that. Keeping the data elsewhere might give you trouble further down stream.
A small delay at this point to get a good design in place would get my vote. It would also give you a chance to learn some of the options available and get some skills transfer.
Ideally you'd get the CMDB data that is stored in your process into the CMDB proper and then the bit in the manual will all come good. I suspect it will be possible to do this, but someone is going to need to spend time working out that design
Thanks for your reply.
I'm not sure how the CMDB differs from the SQL backend that we are using for our database items.
I guess I have a lot to learn. I work for a smaller company and it's my job to make LANDesk work. The process is mine. The concept, design and implementation is mine. The software is paid for. I've taken the five day boot camp. I simply need to make it work now.
You could do it this way for sure.
Can I make an attribute (say, a boolean) on my CI window and link it to the Request window that checks off 'unavailable' when the request is made? Then when I query my requests, I make sure that I'm filtering out that attribute?
This is how I do an equipment check out process. I have a boolean that gets tripped automatically in the workflow based on and action that is triggered. All you have to do is add that boolean, drag that CI BO into Request to make a relationship (not collection) and give it a new name then on the association within request create an action name "Make Unavailable". Then on your form use that newly created attribute for your CI name then in the process use that action to flag a boolean.
May not be the most "optimal" design currently but should work.
After giving it some thought and rethinking my process a bit, I think that the linking/unlinking solution actually makes the most sense and ends up being a lot more elegant.
Thank you all for helping me brainstorm. This is all part of the process and learning about linking/unlinking has opened some doors for me.
Here is how I imagine it working.
- I import my list of CIs from a spreadsheet
- I link the entire list to the person who will be prepping these CIs (in this case, laptops) for distribution
- That person preps them, fills out a virtual checklist, then when he closes the ticket, I have an automatic action unlink the CIs from him
- The CIs are now unlinked and available for allocation
^ I think that's pretty much spot on what I want to do.
I just need some help creating the linking process. I want to basically fire a simple process, have it link all unlinked CIs in my system.