Difference between revisions of "Integrations"
(→Model mismatches) |
(→Integrating Charitylog or Crossdata with other systems) |
||
| Line 4: | Line 4: | ||
[[File:api_3rdparty.png]] | [[File:api_3rdparty.png]] | ||
| − | Integrations are where 2 systems "talk" to each other | + | Integrations are where 2 systems "talk" to each other. This can help to streamline business processes which require functionality from more than one system. An example might be where activity is recorded in our system, and invoices for that activity generated in an accounting system. |
| − | |||
| − | |||
| − | |||
| − | An example | ||
| − | === | + | The are 2 main scenarios discussed here; the first is considerably easier than the second. |
| + | * Where the functionality and data in each system is descrete, i.e. does not overlap. | ||
| + | * Where there is overlap. E.g. if you have a care management system and a CRM, you will typically have identical data, such as a client record, in both systems. This data needs to be kept in sync to avoid double data entry and divergence. | ||
| + | |||
| + | ===Non overlapping=== | ||
| + | An example of this is the [http://www.Loqate.com Loqate] integration. This adds a button next to each postcode, and shows a list of matching addresses to save time when creating client records. This is a single business process: capturing a client's contact details, that requires two pieces of software. Loqate provide the postcode lookup, and our system manages the client record. There is no overlap, because Loqate does not have a client record, and Charitylog does not have access to the Royal Mail postcode database. | ||
| + | |||
| + | ===Overlapping=== | ||
Where systems overlap, e.g. a mailing system and a CRM, an accounts system and a CRM, or a care management system and a CRM, identical data will often need to exist in both systems. | Where systems overlap, e.g. a mailing system and a CRM, an accounts system and a CRM, or a care management system and a CRM, identical data will often need to exist in both systems. | ||
The principle of integrating two such systems is straightforward: where an overlapping data point is changed in one system (e.g. a client moves house and their address changes), the API of the other system is automatically called to make the same change. In this way, the overlapping data is kept in-sync. There are numerous challenges to consider though, which are often referred to as "model mismatches". | The principle of integrating two such systems is straightforward: where an overlapping data point is changed in one system (e.g. a client moves house and their address changes), the API of the other system is automatically called to make the same change. In this way, the overlapping data is kept in-sync. There are numerous challenges to consider though, which are often referred to as "model mismatches". | ||
Revision as of 09:54, 14 January 2021
Contents
Integrating Charitylog or Crossdata with other systems
Integrations are where 2 systems "talk" to each other. This can help to streamline business processes which require functionality from more than one system. An example might be where activity is recorded in our system, and invoices for that activity generated in an accounting system.
The are 2 main scenarios discussed here; the first is considerably easier than the second.
- Where the functionality and data in each system is descrete, i.e. does not overlap.
- Where there is overlap. E.g. if you have a care management system and a CRM, you will typically have identical data, such as a client record, in both systems. This data needs to be kept in sync to avoid double data entry and divergence.
Non overlapping
An example of this is the Loqate integration. This adds a button next to each postcode, and shows a list of matching addresses to save time when creating client records. This is a single business process: capturing a client's contact details, that requires two pieces of software. Loqate provide the postcode lookup, and our system manages the client record. There is no overlap, because Loqate does not have a client record, and Charitylog does not have access to the Royal Mail postcode database.
Overlapping
Where systems overlap, e.g. a mailing system and a CRM, an accounts system and a CRM, or a care management system and a CRM, identical data will often need to exist in both systems. The principle of integrating two such systems is straightforward: where an overlapping data point is changed in one system (e.g. a client moves house and their address changes), the API of the other system is automatically called to make the same change. In this way, the overlapping data is kept in-sync. There are numerous challenges to consider though, which are often referred to as "model mismatches".
Model mismatches
Examples and potential solutions might be:
- Different field types. E.g. the title field (Mr, Ms, Dr etc) in our system is free-text, but in other systems is a selection list. The free text field could contain an uncommon title, such as Dame, which might not be in the list in another system. One option would be to only attempt to sync such a field where the possible values are identical.
