Is there a way to send an email and Archive it to an Account Record with BPM?

hi Bud Hartley 

My immediate thought is you can use the Email Archiving SNIP feature - you'd need to enable it via Admin > Email > Email Archiving.

Then use that unique email address within the BPM Send Message as a BCC.

Hope that helps, although I agree an enhancement for BPM to have this feature would be great.

Vincent

Do you need SNIP?

I wonder if on BPM (have not played with it yet, sigh) you could call a custom entry point after sending the Email passing the AccountID and resulting EmailID and add a relationship between the Email Bean and the Account Bean that way?

If you go the archiving email route, you can create an Inbound Email address that is defined not to create a case and BCC that address. However, Sugar will not relate the Email directly to the Account but it will show the email on the account because the email address of the account is in the emails_email_addr_rel table related to the email.id. 

I don't know if the SNIP solution that Vincent Amari proposed takes the extra step of relating the email to beans like Account, Contact etc related to those addresses or not.

We use an Inbound Email for AEs to be able to archive emails they send from their own email client. They BCC an "interactions" email address which goes to a mailbox read by Sugar that is one of our inbound email mailboxes.

We then take it a step further and process those inbound emails so we can also forward to the "interactions" address any replies received from the customer. In the case of a forward the To address is interactions and the From is the AE who received it, we then parse the text for the headers to identify the original To/From and swap those in so the email is recorded as From the Customer To the AE by changing the entries in the emails_email_addr_rel table.
We've been doing this since v6.x first with an entry point and later with a custom Scheduled Task, it's not perfect and increases email volume for our mail servers but it works.

We used to also look for leads/accounts/contacts/targets/users related to the participants of the email and add entries in the emails_beans table for those but that was getting hard to manage and inconsistent when a lead was added with the same address later on, people could not understand why some emails had emails_beans entries and others did not.
Now I tell people to ignore emails_beans in every SQL query we run for emails and use the emails_email_addr_rel so we get much more consistent reports. 

I know that a better way to connect external email clients to Sugar is with Sugar Connect but it boils down to costs.

FrancescaS

NB. We are an on-premise customer and may have more flexibility in creating multiple inbound email mailboxes than a Cloud customer.

Thanks Vincent Amari,

We do use the Email Archiving function with the address for our system.  The internal emails (user to user) that are about an account are archived to that Account record (when they do it properly).

The thing I'd like to do is to be able to archive a BPM created email to the account record.  For example, I have a BPM set for Credit Application processing.  Part of that process sends reminders to users when certain fields aren't updated over time.  The Archive email address could be included, but the notice isn't attached to the account unless it's done after the fact.  I've tested the approach and the result is the same as a user doing a user-to-user email with a BCC to Sugar instead of doing the Send and Archive function.

Hi Francesca Shiekh ,

We're in the On-Demand environment and are avoiding any custom code.  I rely on the Studio and BPM functions to do everything.

Inbound emails from customers that are archived and any internal email that is forwarding a customer communication is attached to the Contact and rolls up to the Account.  The management "beatings" :-) enforce this for internal communication.

My response to Vincent gives an example of what I'd like to do.  As you know, the Email module is somewhat limited and there are a number of Ideas posted asking for more function.

Again, I don't have access and don't want a lot of custom code in our instantiation.

I don't blame you. There is so much that one "can" do in Sugar, but it does make things harder and harder in terms of upgrades. Yes, it;s all through the Extension Framework, but it can become a LOT to manage. It is nice that you are able to have management do the "beatings"

Yes, the "beatings" solved a big problem... Have a GREAT weekend Francesca!