Intent Proposal: StartEmail

[pauldyson]

Enhancement Request

Use Case

A Salesperson is IMing with a Buy Side fund manager who requests a follow-up set of information including research links and some detail on upcoming meetings. The Salesperson promises to send over an email with the relevant information and so wants to open a draft email to the fund manager to start the process off. One click takes the user to the CRM with the relevant individual selected as the recipient, the regular template for client emails opened and the research archive available to quickly add research links.

Intents

StartEmail

StartEmail should be used when a user wants to create an email to send to an individual or a list of individuals. StartEmail would be called with the Email context.

Contexts

The fdc3.Nothing Context can be provided to initiate the Start Email workflow with a blank email

Email

The Email Context allows the passing of all the relevant information to provide the user with a well-drafted email.

Property	Type	Required	Example Value
type	string	Yes	'fdc3.email'
recipients	fdc3.Contact or fdc3.ContactList	Yes	{ type: "fdc3.contact", name: "John Doe", id: { "email": "john@sample.com"}}
subject	string	No	'The information you requested'
textBody	string	No	'Blah, blah, bah
richTextBody	richtextblock	No	See #575

Example

window.fdc3.raiseIntent('fdc3.StartEmail', {
    type: 'fdc3.email',
    recipients: {
        type: 'fdc3.contact',
        name: 'Jane Doe',
        id: {
            email: 'jane.doe@example.com'
        }
    },
    subject: 'The information you requested',
    textBody: 'Blah, blah, blah ...'
})

Additional Information

This rounds out the StartCall and StartChat intents to cover all the main communication methods.

[pauldyson]

Updated following our discussions:

1. Rounded out the use case a bit
2. Reviewed the mailto spec. The only thing from the spec this doesn't support is CC and BCC. These are irrelevant concepts in the personalised, tracked, distribution email world but I could add them in for a more general case
3. Email context spec
4. Example

[rikoe]

@pauldyson is there a need to consider attachments, e.g. an application wants to initiate an email that also includes attachments.

Maybe it is out of scope - I don't think we have the ability to include binary blobs with messages at the moment.

[kriswest]

@pauldyson is there a need to consider attachments,

We did discuss that. Attachments would rarely be included as a binary, rather the CRM or similar would attach them and log the fact that they did. Hence, a way to reference content that should be attached was suggested. If memory serves I think @pauldyson commented that the user would usually use the UI to add that but that there might be a use-case for being able to specify something in future. I imagine a context could help filter or search for possible attachments (e.g. by instrument, organisation etc.)... but this is a at least a step removed from the attachment itself.

Correct me where wrong @pauldyson

[pauldyson]

@rikoe I think this potentially opens a world of hurt. Maximum attachment sizes, attachment mime-types, etc. etc. That isn't to say it's not a consideration but most use cases I can think of don't require attachments (e.g. in chat, need to send the respondent an email, what would you attach from here?). My proposal is we don't worry about them for now and if there are clear use cases that require them then we can do a v2 of the intent to support them.

[rikoe]

Agreed @pauldyson. Sounds like a bridge too far. You can always drag-and-drop or attach manually once the email has been opened.

[kriswest]

Camel case on property names is the usual convention - is it ok to switch the properties to camel case?

[pauldyson]

Updated property names to the correct convention. Will submit PR.