Hi,
We need to email a distribution list (100+ users) of all identities that are inactive.
We can’t give that many people report access, AND to access our PROD environment requires JIT provisioning signed off by senior staff, which makes the whole thing ideal for automation.
However, the two threads below suggest that you can’t currently attach csv files to emails via Workflows. Those threads are quite old, but I’ve not managed to build a workflow that does it either.
Has anyone resolved this problem?
I’ve written a PS script that gets the info, but our network prevents scripts for sending emails via smpt.
It might just be easier to make it a scheduled, manual, task.
Wouldn’t you be able to setup a saved search and setup a subscription to it? That way you can have the search results (all inactive users) emailed as a CSV to a distribution list address.
Just a thought.
Matt
No, we can’t do it that way. it would be really nice if we could though
Maybe I am misunderstanding what you mean by distribution list. Is it just a single address in Google/M365/other that delivers emails to its members? If so, no one needs access to ISC. They just need to be in the DL that is set as the recipient of the saved search subscription.
Matt
Hi Matt,
The members of the DL receive the subscribed search without a problem. However, when they try to open the csv file, they get re-directed to ISC. Where upon they need JIT approved access to be able to get on, and Report Admin level.
We are trying to get around that and just give them a plain old csv file.
Got it - you’re right. For some reason I thought I remembered it sending the report as an attachment, or at least there being an option to do so. Apologies.
Matt
NP. Its really annoying that its a re-direct rather than there as an attachment
In my head, this doesn’t feel quite right at a process level. Ignore the ISC technology for a moment. You have a process that implies 100+ people need to know the full list of inactive identities, delivered via email, to each individual’s inbox. I’m probably judging too much prematurely, but it sounds like 1. Process inefficiency. 2. Lack of accountability (We expect every one of the 100+ recipient to be equally accountable for the processing of the list?) 3. Data proliferation. 4. Automated spam mail? Or misusing inbox as data archive?
A potentially more ideal approach (maybe) could be this…because it sounds like you have a data distribution use case:
Have the external script to download the report, and upload it to SharePoint (if that is an option).
This way, SharePoint can audit who accessed the file. (Instead of email which is fire & forget). Limit the access to the uploaded location via group membership, of course.
The users can subscribe to SharePoint content changes as they see fit, or unsubscribe if no longer needed to be notified. i.e. Add in a bit of self-service notification.
Morning Terry,
The use case for this scenario is that we currently have 100s of unlinked applications. The purpose of the email is to inform all owners/admins of the applications that someone has left the business and needs there access removed from the source system.
That being said, I quite like your idea of uploading it to a sharepoint site and having the end access it. It would also create a an audit trail which I’m sure the auditors will prefer. Thanks, I will investigate the possibility
I’ll keep this up to see if any has managed to solve this issue via workflows.
You could send the email in HTML format and create a table with the data within the email itself. If you’d like, we’ve done something similar here.
Thanks for the idea. However,
If I’m doing it by PS I might as well attach the csv file for ease of end user functionality.
If I’m using Workflows, its going to fail. There are over 2000 inactive users, and there is no hope in LOOPing through that many people.
We made a beanshell Rule that extract data (using query option you can extract more then 2000 rows without problems selecting only the info neaded) and then send email with html table inside.
List foundTasks = new ArrayList();
// 1. filter definition
QueryOptions ops = new QueryOptions();
ops.addFilter(Filter.isnull("completed"));
ops.addFilter(Filter.lt("launched", cutoffDate));
ops.addFilter(Filter.or(Filter.eq("type", "Workflow"), Filter.eq("type", "LCM")));
// add ordering by launch date
ops.addOrdering("launched", true);
// 2. use a list to store the coloumn name
List fields = new ArrayList();
fields.add("id");
fields.add("name");
fields.add("launched");
Iterator it = context.search(TaskResult.class, ops, fields);
while (it != null && it.hasNext()) {
Object[] row = (Object[]) it.next();
foundTasks.add(new TaskDetail(
(String)row[0],
(String)row[1],
row[2] != null ? sdf.format((Date)row[2]) : "N/A"
));
}
sailpoint.tools.Util.flushIterator(it);
Sounds good… Also, on the SharePoint side, you have centralised versioning, and there’s no more “I didn’t get that email” situations.