If Location is a primary key for the database then how does building and area relate to that key once it is defined. A location populates across modules so is the new module just referencing a master table, or that depends on the product. An example of this is the manufactures list in IT_Direct is different from mine in PM_Direct and Maintenance_Direct. So neither of us can see each others manufactures but if the IT_Direct users enable a Location/Building pair that doesn't match our modules, we can't add information to their entry such as student number or square footage of the building and that information is not important to them. Also if the Administrator that set up the entry in the first place is no longer in the district, then how do we correct mistakes. Does anybody have a flow chart for the system, the basic set ups should be in the manuals indicating what data will populate when modules are linked and what is shared. The IT_Direct users had no idea they were in conflict with me and are not in the same location that I am. This has created anomalies in the data structure across all the products that the district uses. In this case simply disabling or thumbing something down will not correct this. I'm hoping that there will be a way to salvage this system and the points made here will assist other large districts from encountering similar issues within their organizational structure.