Victor

@ArmandoDM might be able to help you with this...

@Paul Alexander not directly via the routing rule...but, on top of my head, you could have the BP in a suspend state waiting for an update...when the update happen the BP resumes. Have the next step in the process check for request status. If is "on hold" change it to "open"... you would need to loop that to cater for multiple updates during request timeline... if this does not make much sense, export the BP configuration, post it here and I can have a look and see if, how,...

@lee mcdermott .. I need some examples, like request references and emails (don't need to post the content of the email here, I can trace it in your mailbox)...

@Joyce you really like to give us a challenge .... I'll have a look tomorrow morning... On top of my head it should (emphasise on "should) be doable using multiple measures and again, multi series...

@yelyah.nodrog give me an example please? like what analyst raises the request and what team they assign it to....

@Joyce you need something like this?

ahhh... "All those moments will be lost in time, like tears in rain" ... I really should be getting back to work

@yelyah.nodrog you can manage this behavior via these settings:

@derekgreen yeah the original is bril!! ... but you need to see the series too, is amazingly written...acted as well... Hopkins in Dr. Ford's role...omg!! ... Looking at his speeches I'm like a teenager drooling for Justin Bieber...

@derekgreen your words mean nothing to me! ... or to quote from one of my favourite series, Westworld, "What door?"

@lee mcdermott if you men having a different "customer" on the request than the user which is logged in, then no... not currently possible...

@derekgreen I assume you have SLA(s) with Service Levels and have defined rules to what Service Level to be associated to a request based on certain criteria... Is it possible that on the request missing the Service Level, the rules criteria did not find a positive match? This would explain why you have an SLA but no Service Level.... (I know that I am risking a life of a kitten by stating "I assume" but I am fairly confident it won't be the case )

@Ralf Peters First of all I would really not advise to play around with SQL updates and inserts. I understand that you have knowledge in this area however, things can break so easily... I've seen tables wiped out, for example, by an incorrect statement or forgetting to add a correct filter and so on... But you are right, the user profile settings are stored in this table and a record is created once a user changes any of these settings...You could create a record for each user ID however I am unable to advise further. If something breaks or not working right we would be unable to assist you in fixing it. I hope you understand this and the reasons behind this... What I can advise is to at least try with one or two users then, after a thorough testing, do this for any other...

@Steven Boardman you should know by now, Victor is always right

@Joyce I was lying... It has nothing to do with percentage or count measures when using measures.. measures are built to show data using certain frequency - i.e. weekly, monthly, etc. (which is not something you actually need for this particular widget)... From what I understand you need a widget displaying active incidents... So, ignore the rubbish post I made previously... Did a bit more digging and played with widgets a bit and came up with this: This displays/counts only active incidents (status is new, open and on hold). The sample period is actually specified in the widget and in this example is set to pull all data from the start of calendar year (this can be changed as required). The widget is not using a measure, is actually using a custom SQL with multiple series added (a separate series for each priority)... You can also change the looks do display the series as stacked but I don't really like how it looks...

@Ralf Peters there were a few changes around profile visibility but nothing recent (meaning nothing changes since last year)... The default visibility for profiles is "Followers". This is hard coded. If a user changes the visibility of a certain section then we have a record of this in the database... Therefore: won't matter since you can't change something is if not there (hope this makes sense). There is no easy way to bulk changes this, actually there is no way to change this by any other than the user changing them himself... I had a look and see if I can build a quick tool to call the set profile visibility API for a list of users but that won't work either...because the API takes the user information from the session variable, it is not passed as a parameter... there is a way to build a tool but is not quite simple... I can have a look and see if-how-when can be done... I'll also ask our dev team to see if they can expose the default visibility configuration in the admin UI so an admin can change the default values for these which are used when a user is created...

@Joyce I think is easier to show you... Is it ok if I create a test measure and a test widget in your instance?

@samwoo fixed in next build.

@Joyce maybe you could have the measure to use "Percentage" as value aggregate rather than "Count" (it still does the count, but allows multiple counts... so to speak) So, try and amend your measure (one of them, since I assume you have two) to have "Percentage" as value aggregate. This type of aggregate also requires a value column. Set this to be the priority. Then, refresh one of the widgets and see what it gives you... it should give you now a breakdown for teams on each priority...

@Ralf Peters depends how the coworkers set this information (contact details) in their profiles... if this section is not set to public then not everyone will see this... ( @Ehsan thanks for the tip )

@Gary@ADL : as @alextumber suggested, you can view the full error by inspecting the logs in the admin tool (System -> Monitoring -> Log Files). You would need to look at ESPServerService.log file. Filter out to display errors so you can find it faster. However, many times the error will not tell you exactly what went wrong, unless you have some coding/development understanding. Without looking at this issue, I bet is an "Input parameter validation" error which does not tell you exactly why it didn't work...

@Rohit Govind the fix (for this issue) is included in the next Service Manager update. However we have not yet deployed this update in live instances. It is scheduled for mid-end of this week (look for SM build > 956). The deployment is posted in the "Announcements" section of the forum as well.

@Sonali Not really, what I was saying is that the "Assign to Request Creator" node needs to have a team. It's a mandatory parameter. EDIT: Actually, whilst I did not say this specifically in my above post, as per my last paragraph, you statement is correct A request can't have an owner without a team. The "Assign to Request Creator" node will assign a request to a team and an owner, the owner being the analyst that raised the request. So, the node knows the owner, what the node does not know is what team? This is why I said the node must get this info from somewhere, whether is set manually in the node or it can be passed by a previous "Get Request Details" node IF the request has a team assigned when the BP reaches this node. There is also a specific scenario where the request will not be assigned to the analyst that raises the request: If the analyst raising the request is not part of the team specified in the node or passed from a previous "Get Request Details" node (e.g. when the request was raised it was assigned a team of which the analyst is not a member of). In this case the request will be assigned to the team, without having an owner.

@Sonali right, I think I found why you getting the error. The "Assign to Request Creator" node needs to have a team. The team can be either specified manually in the node or it can be passed by a previous "Get Request Details" node IF the request has a team assigned when the BP reaches this node. Suggestions: A. Have a decision node before to check if there is a team on the request. If there is no team on the request, have a "Assign to Request Creator" node with a team configured (set "Team" parameter to "Manual" and specify a team). If there is a team on the request you can have the "Assign to Request Creator" node with all parameters on "Auto". B. Amend the current "Assign to Request Creator" node to always have a team configured (set "Team" parameter to "Manual" and specify a team) for all scenarios (request having or not having a team).