Best Practices for Extending FDC3 with Custom Intents and Contexts for Back-Office Applications?

[jfbaro]

Hello FDC3 Community,

I’m looking for some guidance on using FDC3 in a broader way than it might typically be applied. From what I understand, FDC3 (up to version 2.1) has been particularly strong in trading and front-office contexts, which aligns with the current standard list of Context Data and Intents.

However, our leadership has decided to extend FDC3 across a variety of back-office applications (all web-based), including areas like MDM, Compliance, Document Management, KYC, and more. While this isn’t FDC3’s primary focus, we’re doing our best to make it work within the standard.

Custom Intents and Context Data We’re Considering
Here are some examples of what we think we’ll need:

Intents:

• OpenCase – Opens the correct app for a specific customer case.
• UpdateTaskStatus – Updates the status of a task within a case.
• ReviewAMLAlert – Launches a compliance tool for handling AML alerts.
• InitiateTransfer – Starts a transaction, like a transfer or deposit.

Context Data:

• Case – Customer case details, like caseId, status, and priority.
• Task – Data on individual tasks within a case, like taskId, description, and dueDate.
• FinancialTransaction – Transaction details, such as transactionId, amount, and currency.
• KYCProcess – Data for compliance steps like KYC, with fields like customerId and verificationLevel.
• DocumentLink – Links to legal or compliance documents related to cases.

One major use case is our Customer Case Management system. In that scenario, what would typically happen would be: a back-office agent would see a list of tasks queued for them (to solve), and clicking on one would trigger the right FDC3-compatible application to open with the relevant case information already populated. This way, the agent wouldn’t need to re-enter details manually.

Initially, we considered a simpler approach where each case type in the Case Management System had a pre-configured URL (stored as a field in the Case Object). When the agent clicked on a case, we’d launch that URL with the case ID attached, allowing the destination system to retrieve data from the Case Management system via an AP provided by the Case Management SystemI. But for a more consistent experience across applications, our leadership decided to move forward with FDC3.

Since many of the custom Intents and Context Data we need aren’t part of the current FDC3 standard, what’s the best, most “future-proof” way to handle these custom items while keeping everything as compatible with FDC3 as possible? For instance, is there a way to use a META Intent or META Context Data to describe itself to the receiving system?

I’m investigating and would love to learn from the community’s experience here.

Thanks so much for any advice or insights you can share!

[robmoffat]

Hi @jfbaro ,

This is awesome and is exactly what we hoped to see by building out FDC3 for the Web! Tagging @mistryvinay for visibility. We can either discuss async here or pick it up in an FDC3 Use Cases and Workflows meeting soon.

cheers,
Rob

[kriswest]

There is not yet a 'META' approach to context or intents, hence, IMHO the best way to future-proof your use of custom intents and contexts, where they do not exist in the standard already, is to contribute them. In almost every case, the definition of an intent or context type is not valuable proprietary information and sharing it with the rest of the community through contribution will:

• Give you access to independent reviews of the definition (e.g. ensuring that you've applied the best practice and field type conventions for contexts, naming conventions for intents etc.)
• Make it likely that others pick up and use the same definitions before creating their own (which may eliminate future integration work with other apps)
• Make it easier to persuade vendors or other teams that you work with to implement support (most devs prefer a standard over a one-time integration).

The FDC3 maintainers have been working to make contributing contexts easier. We've got that down to creating a single schema file. I hope to record a tutorial on creating and contributing contexts shortly - meanwhile one of the use cases for the Citi India hackathon seeks to provide tooling to simplify it further.

Finally on specific intents and contexts that you propose:

• Consider StartCase and ViewCase, rather than OpenCase (preferred intent name prefixes),
• Consider ViewAMLAlert or even ViewAlert rather than ReviewAMLAlert - the intent is qualified by the context that goes with it so the intent name only needs to be comprehensible within that scope - so ReviewAlert with a Case context may be enough to comprehend what it relates to.
• Consider a Document context containing a link property rather than DocumentLink. The context is representing a document and could be defined by an id, URL, apth etc. Whatever is necessary for an app receiving it to do what it needs to with it.