Difference between revisions of "Integrations"
(→Integrating Charitylog or Crossdata with other systems) |
(→Model mismatches) |
||
| (14 intermediate revisions by one other user not shown) | |||
| Line 4: | Line 4: | ||
[[File:api_3rdparty.png]] | [[File:api_3rdparty.png]] | ||
| − | 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 are then generated in an accounting system. | + | Integrations are where 2 systems "talk" to each other, typically using an API. See [https://wiki.charitylog.co.uk/index.php?title=API_Details this page] for an overview of the Dizions API. 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 are then generated in an accounting system. |
The are 2 main scenarios discussed here; the first is considerably easier than the second. | The are 2 main scenarios discussed here; the first is considerably easier than the second. | ||
| − | * Where the functionality and data in each system is | + | * Where the functionality and data in each system is discrete, i.e. does not overlap. |
* Where there is an 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. | * Where there is an 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. | ||
| Line 18: | Line 18: | ||
==Model mismatches== | ==Model mismatches== | ||
| − | Examples and potential solutions might be: | + | All software has a conceptual model which attempts to represent the real world in some way. These vary from system to system. If the conceptual model of your 2 systems were identical, it's likely that you wouldn't need 2 systems! Integrations must carefully consider model mismatches if they are to be successful. Examples and potential solutions might be: |
| − | * Different field types. E.g. the title field (Mr, Ms, | + | * Different field types. E.g. the title field (Mr, Ms, Miss 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 field types are identical. |
| + | * Different level of fidelity. E.g. if system A may have an field for "how did you hear about us?", which contains broad options, such as "GP Surgery" and "Search engine", and system B may have an extensive list of individual surgeries and search engines. It may be possible to map each detailed item in system B to the broader item in system A, but not the other way round. One option would be to prevent data entry for this field directly into system A, and force your users to enter this in system B, at which point the mapping could be used to automatically sync to system A using an API. | ||
| + | * Different concepts. E.g. some care management systems have the concept of a fortnightly care plan, where week one differs from week two, and the process repeats every two weeks, producing a plan split into "odd" and "even" weeks. A fortnightly care plan in our system simply means an activity which happens every fourteen days. Two such systems could be matched by having two fortnightly plans in our system, with one starting a week after the other. | ||
| + | |||
| + | ==Why Dizions doesn't provide integration services== | ||
| + | Because the model mismatches will vary from system to system, and even within the implementation of a system, Dizions does not offer to integrate directly with other overlapping systems. Instead, assuming the other system has an API, we recommend seeking a third party to produce an application which sits "in between" our system and the other system. This would typically contain the logic for handling the model mismatches, and calling both APIs to provide the necessary integration. Dizions is focussed on developing and maintaining generic solutions for a wide range of third sector organisations, so is not able to offer software development services for integrations. If you purchase our API module, it comes fully supported, so we can offer expert advice to other software companies that you work with. | ||
Latest revision as of 11:42, 2 August 2024
Contents
Integrating Charitylog or Crossdata with other systems
Integrations are where 2 systems "talk" to each other, typically using an API. See this page for an overview of the Dizions API. 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 are then 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 discrete, i.e. does not overlap.
- Where there is an 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. The result is a seamless integration.
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
All software has a conceptual model which attempts to represent the real world in some way. These vary from system to system. If the conceptual model of your 2 systems were identical, it's likely that you wouldn't need 2 systems! Integrations must carefully consider model mismatches if they are to be successful. Examples and potential solutions might be:
- Different field types. E.g. the title field (Mr, Ms, Miss 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 field types are identical.
- Different level of fidelity. E.g. if system A may have an field for "how did you hear about us?", which contains broad options, such as "GP Surgery" and "Search engine", and system B may have an extensive list of individual surgeries and search engines. It may be possible to map each detailed item in system B to the broader item in system A, but not the other way round. One option would be to prevent data entry for this field directly into system A, and force your users to enter this in system B, at which point the mapping could be used to automatically sync to system A using an API.
- Different concepts. E.g. some care management systems have the concept of a fortnightly care plan, where week one differs from week two, and the process repeats every two weeks, producing a plan split into "odd" and "even" weeks. A fortnightly care plan in our system simply means an activity which happens every fourteen days. Two such systems could be matched by having two fortnightly plans in our system, with one starting a week after the other.
Why Dizions doesn't provide integration services
Because the model mismatches will vary from system to system, and even within the implementation of a system, Dizions does not offer to integrate directly with other overlapping systems. Instead, assuming the other system has an API, we recommend seeking a third party to produce an application which sits "in between" our system and the other system. This would typically contain the logic for handling the model mismatches, and calling both APIs to provide the necessary integration. Dizions is focussed on developing and maintaining generic solutions for a wide range of third sector organisations, so is not able to offer software development services for integrations. If you purchase our API module, it comes fully supported, so we can offer expert advice to other software companies that you work with.
