Berto2002

I wasn't around when the system was implemented so not sure how the exact set-up works for the UI interface option to Create New Linked Request. My belief is that we set the SM application setting of "app.requests.defaultBPMProcess.incident" which determines the BPM used in this cases but I cannot see where the IC form is specified... I get presented with the box to enter summary and description and it's pre-populated with the details from the original Request (yellow) so I add-in/alter the Summary and Description, in this case just adding a server name (obscured). And yet when the Request is logged, the new information is 'lost' and all I have is exactly the same Summary and Description as the original record. One of the first nodes in our General Incident process sets the Summary as this: &[global["flowcoderefs"]["getServiceInformation"]["customB"]] Issue: &[global["flowcoderefs"]["getReqInformation"]["summary"]] This is designed to add the 'prefix' from the Service to the Summary. The issue appears to be that the &[global["flowcoderefs"]["getReqInformation"]["summary"]] is putting the Summary from the originating Incident into the Summary on the new Incident rather than using the Summary from the IC form that I edited for the new Incident. Have I got the wrong or have I uncovered a defect?

Normally we get this kind of standard timeline update for a Request: about 4 basic updates as the BPM kicks-in and does it's stuff: But one of my new pieces of work doesn't. It has this, even after Human Tasks have been actioned. Nothing seems to be appearing: This is new on me. have a set something to disable the Timeline?! Literally the first node in the BPM is this which should be putting something:

@Met we have the same issue but we put in place a formal Name Change IC/BPM because we realised lots of people need to know about Name Change anyway. Our process gains approval from the line manager, sends the user and line manager an email detailing all the consequences of the name change, selectively notifies relevant apps teams (look-up into Subscribers lists held as Organisation Groups), gets SDesk to rebuild the laptop, tells our third party telephone provider, eLearning team, supplier team to update vendor portals for software licences, re-issues name badge, etc. When a name change happens, the user import from AD creates a new UserID. And THEN, at the end, the BPM, we do the following in Service Manager: Alter the Customer of the name Change to be the person's new UserID so they can still see that request going forward Find all the linked assets for the old UserID and set their Used By to be the new UserID Remove the old ID from all Organisation Groups Set the old UserID to Basic (in case they were a full User) Set the old UserID to Archived This avoids the 'zombie' accounts. But it does not transfer all the User past Requests across; they do permanently lose access to those and it's one of the warnings we give them. In case of interest our email to the user and their manager is: What we think you have asked for: Our records show that you have asked for the following. If this is incorrect in ANY way, please contact Service Desk immediately to update: New Display/Preferred Name: "{{.H_custom_c}}" New Email: "{{.H_custom_d}}{{.H_custom_i}}" Service Desk will review the above and only get back to you if there are queries before proceeding. Inform HR It's important you realise that ICT and HR do not (yet) have an integrated process so you must also inform HR of this Name Change requirement. ICT do not inform HR or validate this change with them so please ensure you give them exactly the same information. Laptop rebuild at Civic Centre The Name change requires your computer to be re-built and we can only do this in-person at Civic Centre. Service Desk will contact you to arrange a date and time to do this. Please plan to be without your laptop for at least 1 hour, possibly 2, during this period. ICT do not provide courier services so in-person visits to Civic are required unless your business units pays for the (insured) courier or makes other arrangements. If you are not planning to attend in person, please advise Service Desk in advance since they need your password for the work. Software re-installation If you have particular software on your computer, you will need to re-install it from the Company Portal after receiving your newly-built computer. Please allow time in your diary after collection to install this software before you come to require it. Mobile Phone rebuild If you have a Council-issued mobile handset, please ensure you bring it with you for your appointment since it, too, needs to be rebuilt under your new profile. Your mobile number (or your Avaya/Teams numbers) will not change. Your data You should be saving all your data on OneDrive, SharePoint or in Teams but if you know you have Council data elsewhere on your device, please ensure you save or upload it to an online location before you arrive for your appointment since it will be lost in the rebuild process. This applies to laptops and mobile phones and areas to check are your 'desktop' and 'downloads', particularly. Security Badge Please remember to bring your badge with you because you will be collecting a new one with your new name at your appointment and must relinquish the old. Line of Business (LOB) Applications The Name Change process in velocITy includes an automated check of the LOB Applications groups in addition to acting upon the Applications you selected when you applied. A notification of your new name and email address will be sent to the application support teams for each of these applications and they will contact you under separate ticket references with the outcome of each. You should be prepared to spend a little time ensuring that all your applications are working once you get your rebuilt computer. Your old email address Your old email address will be added as an 'alias' to your new account which should mean emails that are sent to that old address are still received. However, Aliases are not guaranteed to work forever so you are advised to be proactive in contacting third parties to change your details. This is particularly important for business systems that rely on your email address to send notifications and password reset codes. Printers You will be re-registered for the printers with your new name/ID. Please make a note to check this works when you collect your laptop/mobile phone after the rebuild to avoid issues later. Peripherals/accessories All your existing peripherals/hardware should still work and not require any changes. velocITy On the day your name is changed and your computer is rebuilt, you will lose access to velocITy for approximately 3-4 hours while your new profile is copied across. You will also lose access to any current or historical tickets in the My Requests section (except this one which will be copied over to your new account). It will not stop ICT working on any active tickets but you may not receive notifications about them. If there is any information from any tickets you need, please obtain and store it beforehand. If there are long-running tickets you cannot close and need access to, please make a note of the reference numbers and contact the Service Desk after the name change is complete and they can manually transfer them over to your new account. After the synchronisation has completed, your single-sign-on to velocITy should be restored automatically. Please remember to have the Name Change Request reference to hand when you visit Service Desk.

How have I missed this... (PS HB will confirm I miss things...) Has it always been there @Steve Giller or enhancement since May 2022 when I posted this on the forum?

Looks like we have a winner here

We use the IC form to capture the change very early, when not much detail is known. We do that so we can Teams/email the listed stakeholders and ask them to get involved in the early planning. We then use a sequence of Human Tasks to prompt the Requester to 'build' the CR bit by bit; which could take them 15 mins or 15 days, depending on the complexity. Each of those outputs is then stored in a custom field and displayed on the Details form (we allow edits of the Details up to the submission to the Change Manager for review or if review requires more information). We need the feature to put that data into the Change Request fields named for that data type

@samwoo, @Adrian Simpkins is this something that would be useful for you? Not got a lot of traction on it! The use case is that we build our changes through BPM not IC forms so populating these when logging the CR is impossible; but then we cannot use these fields later on. Also includes: h_communication_plan h_backout_plan

We hade two instances of 2-3 mins outage yesterday afternoon (10th July) but HB checked and it was not instance-related so we have to go with "in the internet..."

You could also download the bpm. It saves as a .txt file which can be viewed in Notepad etc. You can then search for the team name like this: Any BPM that gives you a hit you can then browse in the UI to find it. Also browser search helps; if you've had good practice to node the purpose of each node in the text:

Nice to hear. I suspect things were pushed back by all the work on the security breach. From my perspective, it was assuring to see the constant stream of updates over the last 3 weeks highlighting that Hornbill took that issue very seriously and have taken this opportunity to upgrade security across the board.

@Gareth Cantrell it crossed my mind that the fields may be there to allow import of legacy versions or other solutions into the SaaS solution. However, James did mention these were for a forthcoming innovation so am I keen to have that come forward... Glad to hear there will be a bunch of other customers out there for whom this may be useful. I am usually naïve on these things but this does seem like a relatively easy thing to do: reveal an existing field in a UI.

@James Ainsworth. Cycling back on this. Use Case: As discussed in a call with @Andre de Waal , we are implementing an Application Portfolio Management (APM) report which includes much information about our apps. The various different types of Owners are important and at present, we are struggling because we're about to use-up the very limited number of custom fields on our Services storing Technical Owner and Business Owner; when you have them in the database schema. I would like to make another appeal for these to fields to be added to the UI so we can use them, please, as indicated above. Please also see my general request for a few more additional custom fields in the Service Portfolio area:

I request (at least) 10 rather than 6 custom fields for Service Portfolio. We are implementing an Application Portfolio Management (APM) report which includes much information about our apps. Since we have a close relationship between line-of-business apps and service portfolio items, we now have more information we want to store against the Service. Examples include the type of authentication, it's operational criticality, strategic importance, owners, etc. However, there are only 6 custom fields in Services. I accept we cannot have unlimited but 10 would be my starter request. I note there is inconsistency in the number of custom fields in various areas. For example, User Profiles have 8, Suppliers have 10, Organisations have 6. Another way to word this is perhaps to suggest consistency with 10 custom fields for each area. See also this post which highlights how we are held back by the fact the Business Owner and Technical are not available in the UI so we need to consume two custom fields for these:

Last release on my instance was 23 May. History implies you're normally monthly. Are we due? I like to look out for when they come and with holiday season coming, etc

@James Ainsworth this totally explains why I thought we had enough licences because that delay was 1 month before they logged on! I did not imagine there would be different ways this 'counted'. Thanks. Hopefully this is a useful reference for others searching the forum.

@StephC I recently asked this and HB Security confirmed that resetting the password for the "system administrator" account would NOT affect the API's associated with it. I asked: "Are there any other effects of resetting that we need to deal with such as whether it disable anything or any of the APIs need to be reset?". HB answer: "There should not be anything depending on this account".

@Lynne Aldridge One of the bits Steve mentioned is the Service Portfolio; you can set the "Supporting Teams" and only people in those teams will be able to see the Requests. Everyone else without admin access gets to see "You are not authorised to view this request" error message. Your Subscribers controls who can log a Request for that Service Take care though, Request data is available through the Reporting Engine so when we implemented our Councillor Case Management solution, we needed to pull-back all our Reporting access to sys admins only. We also, by default, have every BPM set a custom field integer flag (custom 28) as either 0 (not restricted), 1 (Councillor-restricted) or 2 (HR) and every report with Request data also filters on that custom field to either include or exclude such Requests; so we don't get leaks of the data or metadata from confidential Requests.

I feel someone needs to ask you for a bit more information on your use case so I'll make that me

Just remember the Get Timestamp node returns GMT always so you might have to work on ensuring it converts to your local timezone before you use it (e.g. BST) otherwise things may be an hour out for 6 months of the year

I find the integers very useful as "flags" to denote a pathway through a BPM. For example, for our s/w request process, we have about 4 cases go through the same BPM (simple install, licenced install, software with account and new app request). At the start of the BPM I map 1,2,3 or 4 to a custom field depending on IC form choices or Simplelist Values and that determines the path that Request takes through its lifecycle where each stage looks for 1,2,3 or 4. I just needed to make the leap from storing text values for these things to using numbers and now I don't have enough integer fields...!

@Steve Giller. I did indeed find we had a User with SM permissions who was not showing the list in Solution Centre when they had SM perms. I suspect we ended-up here because there is a delay between adding the user's SM roles to their profile and them being counted in the list of fully licenced users in the Solution Centre. I'd given access to someone then checked the numbers (not checked before adding the first) and seen 74/75 in use to proceeded to add another; which would not have worked. Because the user then didn't use it for a month, we've only just found out! So the learning point for others here is that there's a delay before the action of granting an SM Role counts as an additional licence consumed in the Solution Centre; and the system does not stop one adding SM Roles even when licences are exceeded.

Sure we have defined 75/75 Service Manager licences but why are we getting this message? We have under our totoal of overall users:

OK I think I will work around this by putting a wait for expiry node in this particularly important BPM so that 7 days doesn't start counting at the point the Request is closed but, say, 1 month later; thus buying myself extra time but just for this flow.

Someone has just reported an issue to me on a Request that was closed on 17th June. That's only just over 2 weeks ago. The BPM Manager shows "no logs for this process instance" so I cannot examine it. How long are they kept for please? I need longer that 2 weeks.

@CraigP yes. Our other use case is that we have an automatic inbound email from the HR system that logs a Request and the Sdesk are asked to search for a match it with a Leaver ticket the manager has raised. If they don't find one they chase the manager (relentlessly!) but if they find one I want to get SDesk to explicitly enter the ref and use that to link it; but I have to rely on them just declaring they have done so which is less robust from an audit perspective.