Cireson Partners, Customers and Community members share your customizations and examples here to help benefit the community as a whole to earn Kudos and badges.
DISCLAIMER
All files and projects located here are provided and come "as-is" and without any warranty or support. Use at your own risk. Your use of Community Uploads is subject to our Terms of Use.
Cireson does not and will not support or maintain these enhancements, extensions, and scripts.
For Team Cireson uploads click here.
What is the best way to use smlets to create multiple class tickets
Bryan_Lalor
Customer IT Monkey ✭
By default the tickets coming in through the connector is generating IR's which we want. However, we have specific tickets being generated by some PowerApps forms that we would like to come through as SR's
We currently have it set up in custom events to route the entries from PowerApps to specific support groups, but all of those items really should be SRs.
I was thinking possibly putting in a statement under:
function Invoke-BeforeCreateAnyWorkItem {
# This function occurs at the beginning of the new work item function.
}
But I'm not sure how the connector handles passing the, subject to the title, and body to the description, and if telling it to create a Set-SCSMobject -Class "" here would end up doing anything at all if it's before it Creates the work item.
Any knowledge you can provide on where to invoke and how to complete this setup would be helpful.
Comments
@Bryan_Lalor The easiest way would be to create or use an existing shared mailbox, where you send the mails from your power apps to.
Then you configure the mailbox to redirect the mails to your standard mailbox, which you configured in the connector settings.
In the smlet connector settings you define the mailbox in the multi-mailbox tab:
Here you can define your mailbox, where the mails come from, define templates for every workitem type and then define the standard workitem type, in your case an SR.
If you want to create different SRs (I mean different templates) based on the app, which sends the mail, this might be a bit trickier, but also doable. For that you could define an empty SR template (NONE of the OOTB Templates!!) which would be created when an email from that mailbox gets redirected. In the Invoke-aftercreateSR in the customevents you could then then apply another SR template, e.g. based on certain keywords. The thing is, this would apply a second template after the first standard template and I don't know how much impact that would have on performance.
Second way would be to create a shared mailbox for every app and define your templates based on which shared mailbox redirects the mail to your standard mailbox. But these might be intensive to maintain.
Third way to accomplish that would be a rewriting of the standard apply template function, which would not apply the defined template if one of these SRs is created and would therefor just trigger the apply template in your customevents. If you are not 100 % sure what you're doing or if you are unexperienced in powershell I would not recommend doing that, because with that you can destroy the whole connector.
Fourth way would be the usage of the AI part of the Smlet Connector, which creates WorkItems based on certain criteria - But I have 0 experience with it. @Adam_Dzyacky is the mastermind behind that ;)
To clarify the process, set up fowarding from a shared mailbox to the mailbox used in the smlets connector, then define the template as SR. No delegation necessary. I can then likely use the invoke after creating SR to then set the value of the support group similar to what I did for IRs.
You define a template which you want and define the standard workitem type to SR yes.
For the support group there are several ways to do that:
If you have different support groups I'd strongly recommend not to define a support group inside the template. Especially if you have mail subscriptions built on support group assignments, a mail would be sent everytime, even if the support group gets changed later.
Option 3 is really the best - Option 2 would be too workflow dependant and yeah, why would you wait for an activity to trigger, if you can do it immediately "out of the box". We use this for automatical support group assignments on IRs and it works like a sharm. Before the smlet connector we used an SCO Runbook. And as we had a standard support group inside the IR template, in case that no automatical assignment would fit, our helpdesk always received the ticket first (and also the assignment mail). So I can only recommend using the customevents for that.
If you need help with the scripting for the invoke-aftercreateSR, I can help you a bit :)
I believe this should do the trick
switch -regex ($email.Subject) { #set the SR Support group as "Desktop Support" '\[Hardware]|\[Software]|\[Access]' { try { Set-SCSMObject -smobject $NewWorkItem -PropertyHashtable @{"ServiceRequestSupportGroupEnum" = "c62d653d-a8b5-4215-62f4-af94ca155aa1"} } catch { $logMessage = $_.Exception.Message New-SMEXCOEvent -Source "CustomEvents" -EventId 25 -LogMessage $logMessage -Severity "Error" } } #set the SR support group as "SalesForce Support" '\[SalesForce]' { try { Set-SCSMObject -smobject $NewWorkItem -PropertyHashtable @{"ServiceRequestSupportGroupEnum" = "bbbb19ef-b899-bfa3-cbdd-802de4a8cdc8"} } catch { $logMessage = $_.Exception.Message New-SMEXCOEvent -Source "CustomEvents" -EventId 25 -LogMessage $logMessage -Severity "Error" } } #set the SR support group as "Network Support" '\[Telecom]|\[Network]' { try { Set-SCSMObject -smobject $NewWorkItem -PropertyHashtable @{"ServiceRequestSupportGroupEnum" = "a78abb9b-f50d-f822-02a8-3ba9575228f4"} } catch { $logMessage = $_.Exception.Message New-SMEXCOEvent -Source "CustomEvents" -EventId 25 -LogMessage $logMessage -Severity "Error" } } #set the SR support group as "Server Support" '\[Exchange]|\[Server]|\[Critical]' { try { Set-SCSMObject -smobject $NewWorkItem -PropertyHashtable @{"ServiceRequestSupportGroupEnum" = "4f55f978-141f-3ecb-decb-78194cd3f4de"} } catch { $logMessage = $_.Exception.Message New-SMEXCOEvent -Source "CustomEvents" -EventId 25 -LogMessage $logMessage -Severity "Error" } } #set the SR support group as "Developement Support" '\[PRISM] ' { try { Set-SCSMObject -smobject $NewWorkItem -PropertyHashtable @{"ServiceRequestSupportGroupEnum" = "c62d653d-a8b5-4215-62f4-af94ca155aa1"} } catch { $logMessage = $_.Exception.Message New-SMEXCOEvent -Source "CustomEvents" -EventId 25 -LogMessage $logMessage -Severity "Error" } } } }In your script you write "set IR Support Group enum" but then in the function it is the SR enumeration. I hope this is just a typo ;)
It was just a hangover from the IR script I was editing for SRs
Then I guess you are fine ;)
But I'm not sure how the connector handles passing the, subject to the title, and body to the description, and if telling it to create a Set-SCSMobject -Class "" here would end up doing anything at all if it's before it Creates the work item.
Something to be aware of here though is the use of $email, $appointment, and $message variables. $email/$appointment are temporary objects created by the connector to use in all of the functions based on what kind of thing you are processing. They have simple properties that all follow a similar pattern, would contain the decrypted versions of messages, attachments are in the identical location, etc. They are the distilled/abstracted version of the much larger, Exchange $message variable which contains everything before it becomes $email/$appointment.
The thing is, this would apply a second template after the first standard template and I don't know how much impact that would have on performance.
If I had to guess, an extra second or two as the connector runs pretty fast as is. But testing and analyzing the logs in your environment would be the sure fire way to reveal the answer.
Third way to accomplish that would be a rewriting of the standard apply template function, which would not apply the defined template if one of these SRs is created and would therefor just trigger the apply template in your customevents. If you are not 100 % sure what you're doing or if you are unexperienced in powershell I would not recommend doing that, because with that you can destroy the whole connector.
I would wholly echo this. It's doable, but not only do I think its more effort than its worth. But it makes upgrades of the connector harder as you'll have to make sure your copying/pasting your modified version into new version, testing, etc. And yes, its a core function to the connector so there is risk associated with modifying it.
Fourth way would be the usage of the AI part of the Smlet Connector, which creates WorkItems based on certain criteria
I actually would advise against the AI section to solve this particular question. Because it feels like you have some defined "shape" of items and thus, a potentially reliable way of always identifying them. Whereas the AI approaches are trying to infer the following:
I have it set up and running using the method outlined by @Simon_Zeinhofer Thanks for the support. And thanks @Adam_Dzyacky for the additional information. To the AI suggestion. I fully control what comes from our Powerapps workflows as I manage that system as well for our company. The customevent rules fit the need perfectly for handing routing and setting expected subject triggers. There is just lots to learn and I don't have a testing environment to work in currently.
And in case anyone uses the above script, note there was a mistake in the naming used for the Hashtable. it shouldn't be the enumeration list name it should be the binding path.
If I had to guess, an extra second or two as the connector runs pretty fast as is. But testing and analyzing the logs in your environment would be the sure fire way to reveal the answer.
We had that case, when we added a non-empty SR template to be applied when a workitem gets modified in the base connector settings. We ended up having a mixture of activities from the base and 2nd template - So for me I try to avoid applying more than one template under all circumstances :D
I've noticed as well that sometimes the template will take over the fields value even if the custom event flow should be setting the value. I leave anything that is being written to blank to avoid those conflicts.