They're all PEOPLE, right? The same type of entity? Put them all in the same table. Make a field to indicate who is what, even if it's something simple like IsManager, IsSuper, etc. You can have different IDs for different people in your OrderT.

ManagerID
SalesRepID
ServiceTechID

These are all Customer IDs that relate back to the CustomerID in the CustomerT table. This will become more apparent as you get into the Expert classes.

Why not put all the roles (Manager, SalesRep, etc.) in a RoleT table and link it to CustomerT with a many to many relationship using a XrefTable (e.g. CustomerRoleT).
That way you can record extra information in RoleT such as when a person was promoted to manager, when a SalesRep became a ServiceREp, etc. It would also allow for different roles to be played by the same person (e.g. a Manager who is also a SalesRep for high priority projects, etc.). You would then have a full history (via Start Date and End Date) of WHO was involved in WHAT capacity, and WHEN. Just a different way to go.....

William, that is the BEST way to do it. I tried to answer Thomas' question based on his skill level. That's one of the reasons I love the user Badges. I can see at a glance that he's only a Beginner student. Many to many relationships are a lot more advanced. Your way IS the best, however. You must have had a good teacher. :)

Yep, I learnt quite a lot from some Star Wars dude. Strange fellow but a good mentor.

This is exciting. Thank you both very much. I have a lot to learn. I did not know the term, but the many to many relationship possibility exists, and will be best for my intended database design. Superintendents become project managers, and often hop to different contractors. So to me, logically it seems as they should be in a separate table. Now I know these tables can be linked. I also know that if WHO was involved in WHAT is not required, fields within the same table will suffice. Wow, this is fun, but I have a long way to go to get this datbase design done right.

William: Ugh! I'm a Star TREK dude, not a Star Wars dude. The only good Star Wars movies were the first two (New Hope and Empire.) The rest were Meh. Star TREK is where it's at!

Thomas: oh yeah, there's always more to learn. I've been working with Access since 1994 (27 years!) and I'm still learning something new EVERY day.

Richard,
My abject apologies (I blame the pandemic!). Of course you're a Trekky, I knew that.
Some background: I have been in IT for over forty years (that's not a typo!). Last twenty years or so I've concentrated on designing Data Warehouses on Oracle and Teradata platforms, so database design is my bread and butter. MS Access is a different kettle of fish and, although I used it years ago I considered myself a novice until I subscribed to your courses (which are the very BEST, by the way). Many thanks for the continuing education. Live long and..... well you know!!!

Thanks, William. I appreciate the compliments.

Peace, and long life. :)

Well, between the references of live long and prosper, and products being Captain Kirk Shirts in different colors, I I figured you for a star trek fan. I am starting on this quest for a similar reason I decided to start building my own pc 's back in the late 90's. Someone irritated me with a response regarding something I was paying for and decide d that it was not rocket science and I would learn to do it for myself, and did so from then on. Access seems to have grown in leaps and bounds from the late 90's early 2000 version. I look forward to learning it. Thanks for the motivation.

Haha. It has indeed. You're welcome!