diff --git a/docs/stay-with-single-object-type-for-user b/docs/stay-with-single-object-type-for-user
new file mode 100644
index 0000000..d4427f3
--- /dev/null
+++ b/docs/stay-with-single-object-type-for-user
@@ -0,0 +1,36 @@
+
+
+
+
+
+Trevor Lucas
+Hello, I am trying to understand the relationship between Archetypes and Object Templates. Specifically, I'm looking at the built-in Person Archetype and the Person Object Template in midPoint 4.8 and trying to understand how they are linked together so that I can extrapolate them to other Archetypes and Object Templates. I can't see any assignments or links between the two object types within the XML. I have looked at examples within the Workbench and the midPoint demos and have read the Archetype and Object Template docs several times trying to find this answer.
+The end goal is to try to mimic the Workbench and have a Student Archetype for the SIS resource and an Employee Archetype for the HR Resource. Then I would like to extend those by adding Object Templates that could specifically affect the respective Archetype Users. Those Object Templates would have specific name and email constructions, auto-assigned roles, etc, just like the Person Object Template can have by default. Ultimately I'd like to know how a specific Template is applied to a specific Archetype.
+
+Slavek Licehammer
+Hi Trevor. You are looking for objectTemplateRef in archetype configuration. For example: https://github.com/Evolveum/midpoint/blob/master/config/initial-objects/archetype/702-archetype-person.xml#L22
+Having separate archetype for students and separate for employees might be problematic if a single user can be both employee and student at the same time. I'm still looking for a universal design pattern how to represent affiliations, but I'm not sure if there is any. Because different universities are handling it differently.
+
+Trevor Lucas
+Hi Slavek, that's exactly it. Thank you! I see that now in the Person Archetype and am wondering how I didn't see it before.
+I was wondering the same thing about splitting into separate archetypes versus using the Person archetype. We can have Students who are also Student Employees, but I was thinking of handling that with Roles. So a Student Archetype User could have a role of Student Employee and get their account created, roles assigned, all that stuff. These would be different than Employee Archetype Users in ways like software licensing.
+Either way we do it we'll have to have some kind of logic to determine which Person is staff, which is student, and grant them roles that way. Would you recommend for a new midPoint deployment to use the Person archetype and build out from there?
+
+Trevor Lucas
+After pondering some more today, I think it will be the best approach to use Person Archetype and not try to split it out by "user type". We would immediately run into collisions with people who are both Students and Employees, and you can't really make those Users owner of other Users. I think we'll rely on roles and getting those auto-assigned to get people their correct accounts and everything else.
+Thank you, again!
+
+Amol Athawale
+We had also tried to use different archetypes for different user types, however, after some brainstorming we ended up using the single USDPerson Archetype (custom) for all our users (employee, student, student workers etc). I remember reading a statement in the Archetype chapter, that it is not recommended to change the archetype of the user in the entire life cycle. We have  scenarios where employees enroll for full time degree programs and students become full time employees (different from student worker).
+
+Trevor Lucas
+@Amol Athawale
+Why did you go with a custom Archetype rather than use Person? There must have been some benefits that I'm not thinking of. The immediate one would be insulation from changes that get made to "Person" over different versions of midPoint. If you don't mind sharing, what were the pros/cons?
+
+Amol Athawale
+Hello Trevor, I apologize if this isn't the answer you were expecting, but part of the reason lies in my preference for avoiding defaults. Initially, we created a hierarchical structure of Archetypes but quickly realized it wasn't working for us, so we reverted to using the parent archetype (USDPerson). As I'm still fairly new to Midpoint, I wanted to thoroughly understand the relationships between various objects like Archetypes, Object Templates, Resources, etc. Creating custom components wherever possible is helping me do that. 
+FYI - We are still in development phase.
+
+Trevor Lucas
+Fair enough, we are in a similar boat. Very much in development and trying lots of different things. Thank you for the reply, I appreciate it.
+Thank you, Amol! We would have similar scenarios. We also have staff who are faculty, students and student employees who make that transition to FTE (and sometimes back again), etc. Better to keep them all as "Person" or equivalent, especially if Archetype should never change on a user.