#1. It took me a minute or two to find the problem. In it's current form, your WallContacts table requires one record per person per wall. So, if Joe is the owner of a building with 2 walls, he will need 2 records in WallContacts (one for each wall). This is because you're storing the WallID in that table.
Try this: Remove the WallID from WallContacts. Create a new table:
Table: Walls_vs_Contacts (I can't think of a better name)
ContactID (FK)
WallID (FK)
This table will serve as the go between between WallContacts and WallsMaster. So when creating queries, you join WallsMaster to Walls_vs_Contacts to WallContacts.
#2. A less important issue is that your WallInteraction doesn't include ContactID. Also, WallInteraction table can't properly record interactions between the staffmember and 2+ people. If this is an issue worth fixing (that's up to you to decide), you'd have to make an additional many-to-many table like in #1:
Table: Walls_vs_Contacts (I can't think of a better name)
ContactID (FK)
InteractionID (FK)
#3. Depending on how many staff members you have, you might want to make a table with a StaffID and StaffName fields. Otherwise, WallInteractions.Staffname will fill up with "Sheryl","Sherri","Sherryl LastName","S. Lastname", etc. making it impossible to search for all interactions involving her.
Otherwise, you're off to a solid start. I like how you identified and properly named the unique keys in advance. (Oh, and if you think I'm wrong, I probably am.)
It is a very poor practice to expect to maintain the PK/FK relationships from the application. In any db that is nontrivial, data has close to a 100% chance of being changed from other sources including ad hoc queries, data imports, etc. It is irresponsible to think the data in the database is protected because the application has protections. Sure you think that you will force all changes through a webservice or some such, but the reality is that no one is going to add a million new customer records, from that company you just bought, one record at a time through a service. Your database has to be designed to account for the fact that people will change it directly at the source or through other applications (some of which may not be able to use your web service). Further, the application interface is usually more likely to be thrown away or redesigned than the data and when that happens, you may lose all or some of the data integrity rules. In designing databases, you have to think about how the data needs to be protected over time not about what is easiest and most convenient for the programmer or the intial application. A data professional sets up PK/FK relationships in the database because that is where the data lives and it is the best place to set it up to protect the data quality.
I see data from a lot of different companies in my current position and I see all too many that didn't set up their PK/FK relationships in the database because they have data integrity problems that a correctly designed database would not have.
Best Answer
I have never used the relationships tool for anything other than understanding the relationships between base tables on the back end database. I could see however where it would be very useful on the front end if you have many users of your application who write a lot of ad-hoc queries and you provide them queries stored on the front end database which they can use as an abstraction layer. On the other hand, if the users only interact with the database via forms I would think the work to add the queries to the relationship tool and connect them up would not be worth it.