Steve Giller

Yep, that would work

Just a flag - if you're recording Toner Codes and Stock Level you'd need more than 6 fields - CYMK + 4 Quantity fields is 8, and you'd probably want to record the trigger levels for placing an order, too. Also, the difficulty with recording them in the Printer Asset Properties table would be that if you have 4 Model X printers you'd only have 1 pool of CX, YX, MX, and KX toners so the logic to adjust the stock levels would get very complicated very quickly.

In theory, if your alerts and call logging procedures are consistent - whether they are manual, email or whatever - then logging a job for a printer x requires toner y (possibly y-cyan, y-magenta etc.) and this can trigger a script that reduces stock by 1 for that toner, and create a new job to order more stock at a certain trigger level. We've experimented with this and the difficulty has been having a wide variety of printers - the alerts are inconsistent for one thing, and don't even get me started on ordering stock from different suppliers depending on seemingly random criteria ... But yes, theoretically possible, it just requires a high level of organisation at the back end.

Aside from the actual view, surely prioritising Partners should be done by assigning the appropriate SLA at the point of logging, not by looking through a list of calls and checking their names ?

Oh well, it was worth a guess - I'm not on this version yet, so I can't test anything out.

Is it because you have the same column in both of the data ranging options?

A useful (and fairly common) customisation option for an App view would just be to have a list of all fields than can be displayed with a simple [On/Off] checkbox - a more complex version would allow re-ordering the list to customise the view as well.

There were issues with TRIM() and NULL values in SQL - I don't know if these were ever fixed. Have you tried a CASE statement to return a blank string if NULL and a TRIMmed string if not?

Starting with the most basic (and surprisingly common) issue: Are they all definitely closed calls?

If you've received a personal email asking you to raise a job then it's perfectly proper that the "Raised by" time is the time at which you action that request. Taking a rather stupid example, if you were microwaving a ready-meal which stated it took 4 minutes on full power to cook, you wouldn't expect it to be ready 4 minutes after you decided that you were having that meal for tea, would you? Foolishness aside, this is more a scenario for expectation management - your agreed SLAs with your customers have to be clear that a personal email does not constitute a job request, and that should the call be raised from such an email this is a courtesy and as such the call "timers" will only start once the email has been received and acted upon. The easiest way to sell this to customers is to ask them what happens if they send an email while you're on holiday - you can't action an email you don't receive because you're away for two weeks, can you?

That functionality is pretty standard in the social platforms that the collaborative model is inspired by.

Excellent, I'll check that out before we (eventually) migrate Thanks.

On this topic, is the mapping to sAMAccountName hard coded into the product? We've found that mapping to the sID to be more effective, as that very rarely changes when user details are ordered. This does produce other issues, mainly that the sID is not exactly a field that you ever want to be visible, but that's relatively easy to work around.

I've not migrated yet, so forgive me if I'm wrong, but shouldn't there be a "Wait for task to complete" node you can put in the code to prevent the call reaching the resolve node until the task is done?

That might work if tags were completely individual, but if a customer's tag was available globally you'd eventually end up with a long list of often unsuitable services for every search due to overzealous tagging and the random way in which customers think!

As a workaround, and because it's purely cosmetic, wouldn't adding a 4px transparent gap above the actual image fix it?

That would be more intuitive if you had a "Clear" button that added the '0' invisibly for you.

On 2. An OoO should only send on the first receipt of an email from an address - so the only way to get a chain going is if the responses are coming from different addresses each time, or the OoO settings on the customer's end are poorly configured.

If the field has a null or 0 value that will translate to an epoch date of 1st Jan, 1970 at midnight.

I'm pretty sure this is unachievable - how would the software know the difference between a footer image and a screenshot image, for example?

Would the options suggested in this thread be better - you get a name for who's dealing with the ticket, but not a direct number to bypass the proper processes.

Both of these seem to verify that it's insufficient permissions (or a non-existent user!).

For me, as everything, I can see the argument for having this as an option, but I would agree it would need to be on a per-team setting, not global, for the reasons you describe. Personally I would not want to publish individual contact details, otherwise you might as well dispense with the Service Desk altogether and go back to customers having "pet" technicians (an exaggeration, perhaps, but still rife in our organisation) but I have no doubt that there are different structures where this would be essential. On the other hand, once we complete our Skype migration we won't have numbers, just names, so the point will be moot.

While I'm being pedantic - Request Resovled?

If it does that it's not longer a 'Wait for Request Closure' node! What seems to be needed is a 'Wait for Request State Change' (or similar) node that can then branch on what the state has changed to.