Skip to main content

I work for a solicitors and so of course all emails need to be retained and attached to a matter.

 

We have a case type built with K2 that sends emails via workflow and via Smartforms.

 

Has anyone automated the "grabbing" of the email .msg and storing it in a SQL database?

We are doing something similar with emails related to a Project like structure, but this requires that you be able to setup rules on your email server.

In our case we are using Office 365, but the same function is available on Exchange on premise:

First, we use a Mail Flow rule to BCC all email From or To our K2 Service email box (you can naturally just do out if you want)

That BCC is into another email box.

Next you need to setup a Smart Object using the Exchange Broker (the one on the Market that allows reading from an email box)

Be sure to make method for List, Read, and Delete

Next you'll need another Smart Object for your new data store (not sure your requirements there)

Then you'll need to setup a workflow that will List all the emails and then for-each will Read them and then store them using your other SMO.

 

The last thing is then you will need to kick that workflow off once an hour or something.  There is documentation on the help site about how to do that.

 

The only trick here is that you will need to have some way to parse the email and look for your "case" number (or in our case Project Number).

 

We did not find any other way to do this other than using code.  So... we created a small .Net assembly with one single static method that accepted a string and returned a number (our project number).  That method parsed the email text looking for the project number and if it found one, then it returned that number, otherwise zero.  We registered that using the assembly broker and then we passed the body of the email message to that SMO and if it returned value then we saved the message we added the proejct number.

 

Finally, the workflow deleted the mail message and started over and ran the list to get next message.

 

 

That worked for us for 2 months or so...

Then users wanted them to be avaialble every 30 minutes, then they wanted them attached every 10 minutes, then they wanted it immediatly.

Naturally firing off one of these every minute was rediculous, so we put all of the above into a .Net executable and we run that every 5 minutes.

 

 

 

 


Thanks for all that Nathan, I'll pass this on the our Solutions Architect.


Reply