Email Stubsessions
How stubsessions keep email replies attached to the correct stub.
Email notifications use a stubsession to keep a conversation thread connected to the correct stub.
Emails can reach a stub in two ways:
- through a Stubber email mailbox, which is an email address configured on the Stubber domain
- through an IMAP connection to an external email service
When an email comes into a stub, _email_in in stub.data will contain the current sessionuuid for that stubsession.
In most cases, the user does not need to know how the sessionuuid was found. The important part is knowing that it is available in:
Stub Handover With a Shared Stubsession
You can intentionally move an email conversation from one stub to another.
This is useful when a create stub creates a default stub, and the default stub should continue the same email conversation.
The default stub must send its next email using the same sessionuuid from ~~stub.data._email_in.sessionuuid.
After that email is sent:
- the outgoing message is saved under the same stubsession
- it becomes the latest message for that stubsession
- future replies in that thread are routed back to the second stub
In practice, this means the default stub can send an email as if it were continuing the create stub's conversation, and all new replies will come back to the default stub.
Typical flow
- Stub A sends or receives an email conversation.
- The create stub has the current stubsession value available in
~~stub.data._email_in.sessionuuid. - Stub A creates Stub B and passes that value into Stub B data.
- The default stub sends its next email with the same
sessionuuidin thestubsessionobject. - Any later reply in that same email thread is routed to Stub B.
Sending with a stubsession
Add stubsession.sessionuuid to the email notification payload.
When you send using stubsession.sessionuuid, you do not need to set the email subject yourself. Stubber will reuse the correct subject for the thread so replies continue to thread correctly in Gmail and similar email clients.
If you include a subject parameter, it is only applied when Stubber is sending the first message in a thread. For later messages in the same thread, the email service sets the subject automatically so email clients keep the conversation threaded correctly.
If a create stub creates a default stub, copy ~~stub.data._email_in.sessionuuid into the default stub and use that value when sending the next email.
What the user needs to do
- Read the current stubsession value from
~~stub.data._email_in.sessionuuid. - Pass that value into any new stub that should continue the same email conversation.
- Set
platforms.email.stubsession.sessionuuidto that value when the new stub sends its email. - Do not manually set the subject when continuing an existing stubsession.
- Do this only when you want future replies to come back to the new stub.
Important notes
- Reusing a
sessionuuidchanges where future replies are routed.
Use a shared sessionuuid only when you want the new stub to take ownership of future replies in that email thread.