I’m working on 8.3p3, currently we have a rule in a provisioning rule that creates work items for workgroups on revokes during JDBC.
The work item creates fine and assigns to the group but an initial email is never generated like OOTB does.
I’m working on 8.3p3, currently we have a rule in a provisioning rule that creates work items for workgroups on revokes during JDBC.
The work item creates fine and assigns to the group but an initial email is never generated like OOTB does.
Hey Thomas,
That’s actually expected behavior. When you create a work item directly via a Rule (e.g. inside a provisioning rule during JDBC), IdentityIQ doesn’t automatically trigger the notification framework the same way it does for OOTB policy violations, certifications, or lifecycle events.
The default email is sent because the item is created through the standard WorkItem generation flow, which hooks into the NotificationService. If you’re bypassing that and instantiating the WorkItem object yourself, you need to explicitly send the notification.
Options you can try:
After creating the WorkItem in your rule, call context.getNotificationService().notifyWorkItemCreated(workItem); – that should trigger the standard email template.
Alternatively, you can craft and send a custom notification using EmailTemplate + NotificationService.
Another option is to avoid reinventing the wheel and use the built-in provisioning policy → Approval WorkItem mechanism, if possible.
So in short: it’s not broken, it’s just that manual WorkItem creation skips the notification logic unless you add that call yourself.
Hi @thasheider1
You can send custom email notifications in these conditions like this
context.sendEmailNotification(emailTemp, emailOptions);
emailTemp - This is your email template object
emailOptions - This is an instance of EmailOptions, where you specify details like to, cc, subject, body etc