How to record and structure Organisation records?

Ali Shaikh

I have a question regarding best practices for recording Organisations on RE. Say we have an Organisation which is IBM with a global head quarter in USA and then UK HQ and other subsidiaries. What is the best way to store all of this information on RE so that there is some structure to the organisation records. We have come up with the following structure.







Any advice, best practices and suggestions will be very helpful.

Gina Gerhard

Ali - 



What's helpful is clarity on what you're trying to accomplish with these records.  

Do you just need these relationships for information only, or do you need to perform some functions based on these relationships.

• If you just need to structure these for informational purposes, then the relationships you've created between these records is probably enough.
  • It looks like you can go to the top level organization record and see all the related organizations from there.
  • If you structure things this way, you can't necessarily see the relationships across the organizations, only going up/down.  
    • ex: if you're on a subsidiary record you can't see other subsidiary records; you have to go up to the top level org to see the subsidiaries
    • you can create additional relationships between all the records to solve this but it involves a lot of maintenance (depending on how many of them you have).
      • Just like a family, do you create relationships from parents to all the children, and do you then do the extra step of creating relationships between all the child records? Or do you just know you have to go up to the parent record to see all the children.
• If you need to be able to group/grab these records for functional purposes, then you may need to create a more formal structure.  
  • In your diagram, you're showing parent, headquarters, subsidiary and locations for these records.
  • You could think of these as attributes of these records.
    • ex: So if you did create attributes for these then you could pull 'all headquarter orgs' or 'subsidiaries of a specific headquarter org located in these locations', etc.
    • You could use these attributes as elements that you can mix/match to get your groupings.
  • You can then create standard queries to get your groupings and make them commonly available (users can add to their Home page)
    • ex: IBM USA and all subsidiaries
    • IBM - All Headquarter organizations
    • IBM - UK Headquarter and subsidiaries
    • IBM - All subsidiaries only
    • etc.....

Seymour Kelly

Dear Gina

Thanks for your very helpful reply. I am working with Ali on the structure. I would be interested to know what you would suggest for Cons codes to back up the attributes?  Our original plan was to use the Cons codes to denote the position of the organisation within the structure but I think this is overcomplex. It would be useful to know how you are using Cons codes for organisations?



best wishes



Seymour Kelly

Gina Gerhard:

Ali - 



What's helpful is clarity on what you're trying to accomplish with these records.  

Do you just need these relationships for information only, or do you need to perform some functions based on these relationships.

• If you just need to structure these for informational purposes, then the relationships you've created between these records is probably enough.
  • It looks like you can go to the top level organization record and see all the related organizations from there.
  • If you structure things this way, you can't necessarily see the relationships across the organizations, only going up/down.
    • ex: if you're on a subsidiary record you can't see other subsidiary records; you have to go up to the top level org to see the subsidiaries
    • you can create additional relationships between all the records to solve this but it involves a lot of maintenance (depending on how many of them you have).
      • Just like a family, do you create relationships from parents to all the children, and do you then do the extra step of creating relationships between all the child records? Or do you just know you have to go up to the parent record to see all the children.
• If you need to be able to group/grab these records for functional purposes, then you may need to create a more formal structure.
  • In your diagram, you're showing parent, headquarters, subsidiary and locations for these records.
  • You could think of these as attributes of these records.
    • ex: So if you did create attributes for these then you could pull 'all headquarter orgs' or 'subsidiaries of a specific headquarter org located in these locations', etc.
    • You could use these attributes as elements that you can mix/match to get your groupings.
  • You can then create standard queries to get your groupings and make them commonly available (users can add to their Home page)
    • ex: IBM USA and all subsidiaries
    • IBM - All Headquarter organizations
    • IBM - UK Headquarter and subsidiaries
    • IBM - All subsidiaries only
    • etc.....

 

 

Seymour Kelly

Dear Gina

Sorry I seem to have replied to this in the wrong place. So I will try again

Thanks for your very helpful reply. I am working with Ali on the structure. I would be interested to know what you would suggest for Cons codes to back up the attributes?  Our original plan was to use the Cons codes to denote the position of the organisation within the structure but I think this is overcomplex. It would be useful to know how you are using Cons codes for organisations?



best wishes



Seymour Kelly

Gina Gerhard

Seymour - Not sure if I can be all that helpful.  We are a community foundation and dont' have complex needs around 'typing' organization records.  



Our constituency codes (for organizations) are as follows:  

• Corporation/Business
• Estate
• Foundation-Community
• Foundation-DAF/Gift Fund
• Foundation-Private
• Government/Public Agency-NH (have these for other states as well)
• Nonprofit Organization
• School
• Trust-Deceased
• Trust-Living

When we need to establish a hierarchy between org records, we create org relationships using these relationship/reciprocals in our table:

• Parent Organization
• Subsidiary Organization
• Affiliated Organization

We don't really use attributes to go any further in this definition.  Perhaps you could get more granular in your relationship/reciprocal values and you might not need to establish attributes if you want more refinement.