May 1, 2022 11:27 PM - edited May 2, 2022 8:40 AM
Emails that are sent outside of the Conversations Inbox where the agent CC's/BCC's the sender address or forwarding address are being received as 'Visitor'. This is causing conflict with the INCOMING/OUTGOING designations within the conversations webhook.
If an agent sends an email from outside the Conversations Inbox & includes the channel email or forwarding address in CC or BCC then it should be assigned as actor type A- & designated as OUTGOING, as opposed to actor type V- & INCOMING. See here & here.
The 'To' & 'From' addresses on the email are being reflected correctly in the Conversations Inbox. It's marking the email correctly that it is to a recipient from the agent, however it's also marking it as actor type V and INCOMING which is incorrect.
Additionally, when I copied in the channel email address for the first time the first email landed in the spam folder of the Conversations Inbox.
Looking forward to receiving your solution!
May 4, 2022 4:35 PM
Thanks for reaching out about the issues you’re facing. It does look like things are working as designed, but I see why you’re perceiving this behavior as incorrect, and I think we have some room for improvement in our documentation here.
To give you a little more insight into why messages bcc'd to the forwarding address look this way:
- They are designated as “INCOMING” messages because the INCOMING/OUTGOING designation doesn’t correspond to the portal users point of view, but rather to HubSpot’s. Literally, it is a message that is “incoming” to HubSpot - ie: not sent by or through the HubSpot app.
- Similarly, we have no way of knowing who the actor was that sent this message, since Conversations inboxes are “shared”, there is no way to know which agent actually sent it (or indeed, if it was even sent by an agent of the company). They are marked as “Visitors”, and displayed as such in the inbox. Even though the message contains the correct “To” and “From” addresses, the message will still be rendered like an incoming message.
Finally, the behavior you noticed around copying in the account address directly is expected behavior. These messages are always sent to spam, and there is no way to override that rule. There’s more info and context here, but the tl;dr is that we put this rule in place to prevent notification loops.
I’m going to work on improving our documentation, and your feedback is very much appreciated. Feel free to reach out if you have any other q’s.
May 4, 2022 7:33 PM - edited May 8, 2022 9:10 PM
They are designated as “INCOMING” messages because the INCOMING/OUTGOING designation doesn’t correspond to the portal users point of view, but rather to HubSpot’s. Literally, it is a message that is “incoming” to HubSpot - ie: not sent by or through the HubSpot app.
This is going to cause issues with the use cases for the webhook. Emails that are not sent from the Conversations Inbox will not get a webhook event, but if they are forwarded when sent from outside the Conversations Inbox they will be included, but then they get counted as incoming by a visitor, which they are not. This needs to be looked at from the perspective of the developers making use of this webhook & the use cases.
If emails sent from outside the Conversations Inbox aren't marked correctly then what is the point of the forwarding address? Any replies or responses sent by agents from outside the Conversations Inbox are being left out of webhook use cases because they are being marked as incoming emails from a visitor which they are not.
Similarly, we have no way of knowing who the actor was that sent this message, since Conversations inboxes are “shared”, there is no way to know which agent actually sent it (or indeed, if it was even sent by an agent of the company). They are marked as “Visitors”, and displayed as such in the inbox. Even though the message contains the correct “To” and “From” addresses, the message will still be rendered like an incoming message.
If the From email address = the channel address, that is all that is required to know. An email can't be both incoming and outgoing at the same time from the same address, it's one or the other. The main issue here is the webhook has choosen HubSpot portals point of view rather than reality. It's an outgoing email, an agent just sent it on the go from their phone or from Outlook or Gmail, it should not be counted as an incoming email, because this messes with the sequence of the conversation. The webhook should be smart enough to recognise this.
At the moment we are auto assigning the email to the assigned agent if both the sender and receiver are marked visitor by the webhook. We have included mandatory assigning of email channels to agents in our apps documentation. If INCOMING messages' messageReceiver is from VISITOR then we assign the messages' vistor to ASSIGNED AGENT. If messageSender has VISITOR ID then we assign it, if not then we retrieve the VISITOR ID from the contact API via email.
The webhook should be updated to correct this flaw. We shouldn't have to hack the webhook in order to correctly thread conversations together for forwarded emails that are sent from outside the Inbox.
May 9, 2022 4:36 PM
I think it's important to draw the distinction between the inbox client and HubSpot here. For messages that are being forwarwded into HubSpot from a separate inbox client, or even synced into HubSpot directly from Gmail or Outlook, what you see in HubSpot's inbox is not the message itself, but rather a duplicated version of it, inside of a HubSpot inbox. Messages are sent to a HubSpot inbox, which makes them incoming, and if they are sent from the HubSpot app, then they are outgoing.
May 9, 2022 7:29 PM
I understand when an email is sent from outside the Conversations Inbox that the fowarded version of the email is the forwarded version of the email. I also understand that messages to the Inbox are incoming and sent from the Inbox are outgoing. These are non issues. We're talking about the channel address being marked as a visitor. This is the issue & causes conflict with use cases for the conversations webhook as I've outlined in my previous response.
I can only request you re-read my previous response or involve another team member here. I'm not sure what else I can say to explain the issue with the webhook. If you would like to jump on a call I'm happy to have a screen sharing session with you or anyone else in your team.
Looking forward to hearing from you.
May 10, 2022 7:57 AM
Sorry I didn't address your core question - I do understand what your concern is. However, the webhook is working correctly: the channel address is being marked as a visitor because, to the HubSpot inbox it is being managed in, it is a visitor, since it was not sent from within the app.
May 10, 2022 8:30 AM - edited May 10, 2022 9:18 AM
Yes!! To the HubSpot Inbox it is a visitor - this is the issue! This is what needs to be fixed!
To everyone else, it's not a new incoming email! The HubSpot user knows this was sent by the channel address, they know it's an outgoing email! So why is the webhook marking the opposite? It's only incoming in function because the agent has purposely forwarded the email, in the sequence of the conversation - it's outgoing... marking it as the opposite is and will continue to cause issues with the use cases for this webhook.
If an email that has been sent by the agent/channel from outside the Conversations Inbox isn't being correctly identified by the webhook then it cannot be threaded correctly into the conversation! We rely on the type actor designations to know what came from where. Therefore this issue is excluding these messages from being included in any use cases that we are building using this webhook!
The only case where a forwarded email should be marked as V- is when an incoming email (reply) is sent to the agent (if automatically forwarded from the channels mail client).
If either the issue is not fixed or teams do not figure out the workaround we have applied, the applications being built will fail unless every single email is sent from within the Conversations Inbox - which is counter intuitive to the existence of the forwarding address and an unnecessary exclusion that can be easily fixed on your end.