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

The issue we were having started with employee to employee email communication about an account with no record of the discussion being attached to the account record in Sugar.  That was resolved with management beatings :-) and reminders about using the Send and Archive function.

The desire now is to have BPM sent emails attached to Account records as part of the BPM processes.  I don't see a way to make that happen using Studio and the BPM Manager.

I am not hopeful that it can be done, but are there any thoughts on how this might be accomplished?

Parents
  • hi  

    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

     

    .

    CRM Business Consultant

  • 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  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.

  • Hi ,

    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.

    Bud Hartley | Cape Foulwind, NZ (and Oregon, USA)

  • 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" Slight smile

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

    Bud Hartley | Cape Foulwind, NZ (and Oregon, USA)

Reply Children
No Data