Sometimes you want to create a popup for a virtual field you’re using, but when you create an SSHD popup it wants to relate to an SSHD form. This is a complete waste of time in my opinion because the popups in SSHD never go to another form – they’re just used on the form itself. So how do we create a popup without having to deal with that? Simple – use SQL Enterprise Manager or SQL Management Studio! In this post, I’ll walk you through the process!

Read the rest of the entry »

Alright, so now that we have the preliminary items accomplished, now it’s time to get the automation going!

User Defined Function

For our UDF, I spent a lot of time going through and getting each to work. The UDF is used by the Business Rules to give a datetime for the “Next Run Time” field created in Part 1. This field is what the Integration Engine package will look at to see when to schedule the next Task to open. So far, it’s been used about 20 times for all four different types and it has worked seamlessly. Let’s take a look at the code:

Read the rest of the entry »

In our environment, we use Incidents as a “catch all” ticket system. Requests, Issues, Problems, Enhancements, etc. Well, we’re getting to roll out a new item to add to it – Operational Tasks. These tasks can be recurring – some every day, week, month, and quarterly. The rest will be adhoc. Well, for an IS staff member who receives 10 daily tasks each day, we can’t expect the user to open 10 tickets every single day for the same tasks. Nor can we expect the staff member to open those tickets, either.

Enter: Automatically Recurring Incidents.

Read the rest of the entry »

Let’s assume that you need an e-mail to be generated by the Service Desk on a daily basis with a list of all tickets that are in a certain status. Or, maybe you want to send a daily e-mail to Human Resources and notify them of all the User Account Deletions (Employee Termination) requests that have been placed. 

There’s many ways to do it – the easiest way to set this up would be to have a Business Rule that would be triggered once and would be set to repeat infinitely every day. The problem with this is that you’ll have the business rule in the queue all day. While it’s not entirely a bad thing, I’d rather keep the queue as close to empty as possible.

The solution that I came up with was to create an Integration Engine package that would update a specific InActive account which I manually created, then have a business rule trigger on that account’s update. Let’s look at how to do this.

Read the rest of the entry »

I recently had the need to create a form which would link to another form – we wanted to create a hierarchy type ticket. I discovered two things which made this project possible. 

Read the rest of the entry »

Scenario: Our account administration team reuses a username once it becomes available again. So, JSmith could be John Smith who was fired 5 months ago but it could also be Jay Smith that was hired last week. Our SDE environment imports from Active Directory every morning and if we do not do something with John Smith’s account in SDE then “JSmith” will now be Jay Smith and all of John’s previous tickets would now be associated with Jay. We need some way to not only inactivate John’s account but to also ensure that when we import Jay’s username – JSmith – that the import does not fail due to a duplicate username.

Solution: Create an Integration Engine package that will rename accounts no longer in Active Directory to a different username. This would then allow the next JSmith to be imported without overwriting the previous JSmith’s information. 

Read the rest of the entry »