We are working on modeling the Salesforce CASE and JIRA Issues.
Salesforce is our primary CASE tracking system where the customers open their CASE. Most CASEs are resolved as a CASE. However some cases become JIRA Issues. These JIRA Issues are tracked in conjunction with the corresponding open Salesforce CASE.
In addition to this, there are JIRA Issues that are not tied to any Salesforce CASE.
From Business Analyst point of view, the Salesforce CASE and the corresponding JIRA Issues (if one exists) are one and the same entity.
@saqib - From the detail you provided, it sounds like you have two different source systems with potentially the same business key between them, correct? (I’m not familiar with Salesforce, CASE and JIRA issues.)
I believe you have a case for business key tracking using a same-as-link situation. One hub would store your business key, which I assume would be the identifier from each source system. A same-as-link would be built on that hub with FROM and a TO fields to create the relationship when it exists. Thus, when a CASE issue becomes a JIRA issue, two records are inserted in the hub (if they each don’t exist, of course) and one record is logged in the same-as-link joining the two keys. You would also have the two distinct satellites off the hub for the two different sources. If the CASE or JIRA issues remain independent, it’s a simple entry in the hub and the associated satellite.
Of course, as you know, I am recently certified and very open to learning and correction as needed. I would love to hear other people’s opinions and experience.
So based on your suggestion, we would have a single HUB, and then two SATs (one for JIRA ISSUE and one for Salesforce CASE) hanging from the same HUB. We would be inserting the Business Keys from both Salesforce CASE and the JIRA Issue into the same Hub. Then use a same-as-link to tie the Salesforce CASE and JIRA Issue if they are tied to each other.
To quote Neil’s talk last month “it depends”. There are a lot of ways to model entities and their relations, and some of them are very dependent on what a business thinks, or how your sources are limited. In my opinion, the fact that you are talking about Case entities and Issue entities as separate things which have non-overlapping sets suggests that they are separate entities that happen to join up sometimes. To add to complication, the business does not regard them as separate, even though they are.
To me the true test of whether they are separate would be “if a Case exists, and an Issue also exists, is it possible to join them, and from that point they are regarded as the same thing?”.
If the answer to that is yes, then you need to model Case and Issue separately, and add a same-as-link between the two hubs. This can then be visualised going business-ward in the datastream as one “Customer Service Incident” by joining the two entities.
If the answer is no, then there is the question of “is there a common identifier between the systems that isn’t the internal Id of the system?” If the answer to that is no, then they should probably still be treated as separate, as above.
If the answer is yes (there is a common identifier), then that should be your business key, with a unified entity feeding from both systems.
@saqib - @will.list brings up a good point in his response to your question, some things I hadn’t (but should have) considered.
In essence, the question boils down to whether or not CASE and JIRA issues boil down to having “the same semantic meaning and the same grain” (<-- sound familiar?). If so, they belong in a single hub with a satellite for each source and a same-as-link to tie the issues as needed. Otherwise, look at potentially creating separate hubs for the different business keys and joining them with a link accordingly.
There is no common business key from the two sources. However the semantic grain is same.
Can I load the business keys from both SFDC Case and JIRA Issue into a single HUB if the business keys are not same? And have SAL to link the two records?
If they are the same concept you can put them into the same HUB. In this case use a Collision Key, one for JIRA and one for SALESFORCE source key structures. Separate satellites one per source table (i.e. JIRA and SALESFORCE feeds in different tables, if more than one table fed from JIRA/SALESFORCE then continue adding more satellites). Then if you are ever able to match a JIRA and SALESFORCE entry use a same as link to record this.