• Content count

  • Joined

  • Last visited

  • Days Won


Victor last won the day on June 8

Victor had the most liked content!

Community Reputation

92 Excellent

1 Follower

About Victor

  • Rank
    Senior Member

Profile Information

  • Gender

Recent Profile Visitors

605 profile views
  1. @Paul Alexander indeed "Super User" is quite good ... But be careful, "with great power...."
  2. @Paul Alexander what exactly needs updating to this user? Why this person can't log in to the portal? Is there any error of sort? Yes, you can delete users in Hornbill... you (or whoever needs to) need to have "Super User Role"...
  3. @SJEaton oh, sorry, UI = User interface. I meant the BP design interface is more clear and more friendly to the user when it comes to these variables from flow codes now Starting with the latter Service Manager update announcements we now also post links to wiki for any "more extensive" changes/fixes we introduce. For example build 1013 announcement posted here has these links to the wiki:
  4. @SJEaton I think is a very useful addition in terms of UI BP design... ... but I hope this will become familiar once you use it a bit more ... How could you stay away from Hornbill for 3 weeks ?!? Ntzzz...
  5. @nasimg so do you want to explore the option to have the analyst details email sent by the BP what the request is reassigned? The only issue here is that the BP would need to "wait" for the reassignment... reassignment can happen, I guess, at any point during request lifetime so the question would be where do I put these suspend node(s)... or you can do with decision nodes if you have the previous and current owner details available (thinking custom fields) ...where do I put this in the BP... basically all is down to "how do I (fully) sync the BP with the analyst actions on a request"... If you have specific points is the request lifetime when the reassignment can happen then we could (somehow easily) cater for the reassignment in the BP...
  6. To be honest what I would like for our support desk as a feature is to actually be able to forward/reply to a previous email message added to the timeline... So, you add an email from a customer to the timeline, maybe have the option to send a reply to that email...later at some point... You can do this if you trace the email in the email interface, etc. ...but would be nice to do this from a request... Same if you send an email to a customer and you want to follow up on that email from a request... then you will have a nice email trail that a customer can review... The reason why I do the quotes is that I know many people get a lot of emails and be quite busy and is sooo easy to lose track on what was sent 3 days ago if you don't have a sort of "reminder" ... so when you receive something like "Did you get a chance to review our suggestion" (which could have been sent 3 days before) and you don't "quote" this suggestion, people will end up "I have no idea what Victor is talking about"
  7. @SJEaton many things can change in 3 weeks ... I would suggest keeping an eye on "Announcement" section ( where all update notes from all parts of Hornbill are published...
  8. @Ralf Peters Can you give me an example, a screenshot if possible to understand how you do this... is it from mail interface, from a request..?
  9. @m.vandun I would still suggest having the analyst doing the work also resolving the request... actually I feel this should be the right (natural) way since the work is done, so it should be resolved... I understand that changes need to be checked, but that should be ok to be carried out on a resolved request I think... I assume the analyst doing the verification has a task assigned in this regard...once the verification task is completed the request can be automatically closed... the task can have multiple outcomes, one of them maybe doing a request reopen is the request fails the verification... this is just my thought on this... I doubt there will be any change in the way the "resolved by" or "closed by" currently work... if we change this functionality to set the resolved by as request owner, this won't actually reflect the reality, which is who actually resolved the request (performed the resolve action on the request)... If I resolve a request which belongs to analyst A, then I don't think I will be happy to see in a report that the request has been marked as resolved by analyst A, when it was me who resolved it...
  10. @Paul Alexander This looks like an issue that needs to be investigated by support. I would suggest raising a support request with us:
  11. @m.vandun I'm afraid there is nothing needs "resolving"... As you mentioned, the request is actually resolved by the colleague that checked the request. So naturally, this is the information which is (and needs to be) stored in the database. In this case, have the request resolved by the analyst (the request owner) who does all the work once he completes the work... Then the analyst checking the changes can have a task (an activity) assigned to him (for this specific task) and, if needed, the request can be reopened, for example, if the changes are incorrect... Is there any specific reason why the request is resolved by the analyst doing the checking?
  12. @m.vandun indeed it seems the limit is in the Description box, rather than the database field... @Chaz any thoughts?
  13. @Ralf Peters is not the email routing rules that manage the visibility of the timeline update. Is an application setting:
  14. @Ralf Peters I'm afraid I don't know when this will be implemented. This is something @James Ainsworth or @Steven Boardman might have more info about...