Intent Proposal: Create Interaction

[pauldyson]

Enhancement Request

Use Case

An Analyst is IMing with a Buy Side fund manager who has a number of questions about the assumptions made in the Analyst’s latest report on a particular stock. There is a MiFIDII-style service agreement in place with the Buy Side institution and so the Analyst needs to record the fact that the questions were asked and a summary of the questions as a reportable interaction.

Intents

CreateInteraction

CreateInteraction should be used when a user wants to record a new Interaction in a system based on activity in another system as the starting point. CreateInteraction would be called with the Interaction context.

Contexts

Interaction

An interaction is a significant direct exchange of ideas or information between a Sell Side party and one or more Buy Side parties. An interaction might be a call, a meeting (physical or virtual), an IM or the preparation of some specialist data.

Details

Property	Type	Required	Example Value
type	string	Yes	fdc3.interaction
participants	fdc3.contactList	Yes	See below
timeRange	fdc3.timeRange	Yes	See below
interactionType	string	Yes	Instant Message
description	string	Yes	Blah, blah, blah
initiator	fdc3.contact	No	See below
origin	string	No	Outlook

Example

const interaction = {
    type: 'fdc3.interaction',
    participants: {
        type: 'fdc3.contactList',
        contacts: [
            {
                type: 'fdc3.contact',
                name: 'Jane Doe',
                id: {
                    email: 'jane.doe@mail.com'
                }
             },
            {
                type: 'fdc3.contact',
                name: 'John Doe',
                id: {
                    email: 'john.doe@mail.com'
                }
            },
        ]
    },
    interactionType: 'Instant Message',
    timeRange: {
        type: 'fdc3.timeRange',
        startTime: '2022-02-10T15:12:00Z'
    },
    description: 'Laboris libero dapibus fames elit adipisicing eu, fermentum, dignissimos laboriosam, erat, risus qui deserunt. Praesentium! Reiciendis. Hic harum nostrud, harum potenti amet? Mauris. Pretium aliquid animi, eget eiusmod integer proident. Architecto ipsum blandit ducimus, possimus illum sunt illum necessitatibus ab litora sed, nonummy integer minus corrupti ducimus iste senectus accumsan, fugiat nostrud? Pede vero dictumst excepturi, iure earum consequuntur voluptatum',
    initiator:  {
        type: 'fdc3.contact',
        name: 'Jane Doe',
        id: {
            email: 'jane.doe@mail.com'
        }
    },
    origin: 'Outlook'
}

fdc3.raiseIntent('CreateInteraction', interaction)

Additional Information

In this comment https://github.com/finos/FDC3/discussions/545#discussioncomment-2096489 I suggested the use of additional, optional Contexts. This would be a great example of where they could be used. The Interaction Context proposed gives everything required to log a significant interaction but additional information such as Instruments under discussion in the Interaction would only enrich the quality of data in the end system.

[nemery-flextrade]

Could we potentially categorise (at least some of the common) types of interaction, e.g..:

• Meeting (In Person)
• Meeting (Virtual)
• Chat

This could potentially be utilised further down the line to add a CreateMeeting or similar intent?

[pauldyson]

There are some standards (defacto and otherwise) for interaction types already.

RIXML have a standard for Interaction Types https://www.rixml.org/images/docs/schemas/interactions/interactions_2_0/RIXML-Interactions_v2_0_Data_dictionary.pdf (search for InteractionPurposeEnum and InteractionModeEnum).

Commcise are currently the market leader for Interaction Reporting Aggregation. They don't publish their interaction categorisation standard but I could ask them for permission to do so; we know them well.

Or my company - Singletrack - has adaptors for all the aggregators used by the buy side and so we have a scheme that maps all the various standards used by Commcise, One Access, Bloomberg, Dealogic, etc. to a single scheme which is proprietary to us but I'm happy to open it out.

The problem with all of these - including ours - is they suffer from the vast complexity of all the different views of interactions that the Buy Side have and so the scheme are all very large and sometimes hard to distinguish how to apply.

For things like our Mobile App and Outlook integration we take the opposite view; that we can make a good guess based on the client type. You wouldn't likely use a mobile app to log a Corporate Roadshow or a piece of bespoke research; most likely a Call or a Meeting. If you're logging something from Outlook it is most like an Email.

This works well and the functionality is there in our system to review and 'correct' the interaction type should this be an email you want to interpret as 'Bespoke Research' or you want/need to distinguish a Virtual Meeting from a In-person Meeting (which started out being a big thing at the start of the pandemic, and for the purposes of valuing corporate access remains an important detail, but for most other meetings is now seen as an irrelevance).

So if we do come up with scheme it should be limited to likely scenarios instigated from desktop clients. My starter for 10:

1. Instant Messaging (Symphony, BB)
2. Email (Outlook, GMail)
3. Call (telephony systems)
4. Meeting (Zoom, GMeet)

I'm happy we add as many of these as we need, I'd just caution against trying to produce an exhaustive list. I've lived with complexity of all this for the past four years and the simpler we can make it, the more chance we have of delivering something useful!

[nemery-flextrade]

I'd certainly agree we don't want to produce an exhaustive list, I would be happy with some loose categorisations, the four you suggested seems a reasonable starting point, potentially with the inclusion of In Person?

I think that would cover most use cases but as I'm not a CRM expert I'll bow to the domain experts.

[pauldyson]

@rikoe @kriswest just want to bump this back up onto the agenda for upcoming working group meetings. This is a key use case for us(and we already have a working demo based on it). I think the calendar for the WG has expired ... I don't seem to have any more meetings in my diary.

[mistryvinay]

@pauldyson thanks for bringing this issue to the top again. Will ensure we include this in our next working group meeting.

[kriswest]

If the interaction types can't be an exhaustive list as an enum, I see no harm in adding a suggested list to the docs with a SHOULD recommendation to at least promote conformity.

I think the optional additional context could happily be added to the interaction context type perhaps as an additionalContext field typed as Context[] so you can put anything into it.

After the next discussion this could/should move to a PR

[hampshan]

Should we check the iCalendar structure to see what they include?

It makes me wonder if these interactions are just calendar "events" that are historical.

If we had events we could reuse that for calendar type functionality too.

[pauldyson]

@hampshan an interaction is slightly different to a calendar event. It's subtle but it is real. An interaction is something that has taken place rather than something that might take place and is a one-off event. A recurring calendar event (which, regardless of how the underlying calendar system treats it) is one thing but will result in many interactions.

[mistryvinay]

@pauldyson will be raising this one for discussion in this weeks meeting 26th May 2022.

[pauldyson]

Excellent, looking forward to discussing it (the last meeting fell out of my calendar somehow)

[hampshan]

I wonder if we should call the contacts field participants to make the intention clear.

[kriswest]

Hey @pauldyson I had a look into what it would take to create an extensible field for interactionType, (so that we can encourage standard types but leave it open to extension) here's what I think it would look like:

JSONSchema:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": "https://fdc3.finos.org/schemas/next/interaction.schema.json",
  "type": "object",
  "title": "Interaction",
  "allOf": [{ "$ref": "context.schema.json#" }],
  "properties": {
    "type": { "const": "fdc3.interaction" },
    "contacts": {
      "$ref": "contactList.schema.json#"
    },
    "timeRange": {
      "$ref": "timerange.schema.json#"
    },
    "interactionType": {
      "anyOf": [
        {
          "type": "string",
          "enum": ["chat", "email", "in-person meeting"]
        },
        {
          "type": "string"
        }
      ]
    },
    "description": {
      "type": "string"
    },
    "initiator": {
       "$ref": "contact.schema.json#"
    },
     "source": {
      "type": "string"
    }
  },
  "required": ["contacts", "timeRange", "interactionType", "description"]
}

Which basically says any string is fine, but includes a standard list as a prompt.

TypeScript:

export interface Interaction {
  id?: { [key: string]: string };
  type: "fdc3.interaction";
  contacts: ContactList;
  timeRange: TimeRange;
  interactionType: ("chat" | "email" | "in-person meeting") | string;
  description: string;
  initiator?: Contact;
  source?: string;
}

Obviously, the interaction types should be described in the docs page and use the keyword SHOULD (i.e. Interaction instances SHOULD use the predefined interactionType values where possible).

Hopefully, this gives you the main content for a PR to resolve this issue.

[pauldyson]

Thanks @kriswest just working on the PR now so will try to fold it in. cc @milindchidrawar