There is this special app to manage people, but this is currently inherently linked to having a Fibery account. This means that I can’t reference people effectively without rebuilding a completely parallel type for People that links to the official People type, which then creates confusing duplicate information.
I should be able to add as many people as I want without having to invite them with some permission level to use the service at this time. We are building this out with a small team (4) until we gain confidence in it, and this is causing a mess in how to reference people.
I also might want to use the People type consistently for more than just users of Fibery, like contacts. So, I could have a single select and “Person Type” of Employee, Contact, Previous Employee, etc. Right now the People app isn’t very effective in generally managing people information, forcing us to maintain in-parallel another solution.
I just wanted to clarify this isn’t the same thing as adding read only users. I want to have a single place by default to quickly @ mention people in a consistent way. If the person doesn’t exist, then it would quickly be added. I want a People app that can manage people, where a subset of those people are fibery users with permissions. So, this is technically related to my other ticket: Support Adding Types to People App
I also have a need for a robust, customizable “Person” type, that includes the ability to work well with the @mention function.
One solution might be for Fibery to enlarge its existing concept of “User” into a more flexible “Person” Type which Can be customized / extended, like any other Type.
Is there an advantage to being able to @ mention vs. just # linking, as Fibery already allows?
Both this request and the Support Adding Types to People App one just posted take that stance that A: “People” is an app in Fibery (in my view it’s not, at least not by any definition I can see that they use), and B: that the best solution to existing limitations is to expand the existing “People” type/app/whatever so that it can do what you want. I am not sure I agree with this.
I am uncertain of the best approach (and trust that the team will figure that out in time ), but I think it’s worth taking a step back to more specifically define the elements that are wanted/needed here, not as they relate to any existing seemingly related implementation, and think about other ways to approach it that may be more congruent with how Fibery already works. So for example, as I mentioned above, there is a desire to “@ mention”, but what is the specific reason this is wanted? What capability do you hope to get from this possibility, and is there another, perhaps better way to handle it?
My personal feeling is that the existing user management functions should not be “People” and should not be represented as an “App”, though it is indeed at present. Rather than seeing this highly specialized (workspace access control) functionality broadened to work like a type, I would prefer to see user management in its own area, and then to be able to add “Workflows” to any type that would do the kinds of things you are wanting. E.g. one or more of the following: allow @tagging (with what benefits additional to # linking?), linking to actual user profiles/access controls, etc.
In other worlds you build your “People” type however you want, in whatever App you want, then just add the link to actual system users if desired. And if you do, the links are, like any link, optional. Some “People” entities will have “system users” linked, others will not, but the “person” entity will still be useful without it. When such a link exists, it would e.g. connect @s to Activity Stream of that user, etc.
This is a really interesting discussion for me, since I was just figuring out today how to handle the different sorts of people who I needed to represent in my workspace.
I ended up with an Employee type (anyone inside the company) and a Person type (anyone outside the company). I decided that the required fields are sufficiently different to warrant two separate types.
Both have an (optional) 1-to-1 relation to the User type (Fibery primitive), since an Employee or a Person may or may not be a workspace user (with all the permission related stuff etc.)
As concrete examples, I’m an Employee and a User, but the cleaner is an Employee and not a User.
When I get a test report from an external agency, I like to record the Person responsible (but he/she is not a User). If we have a freelancer contributing, they need to exist as a Person and a User.
NB there are no Users that aren’t either an Employee or a Person.
It did make me think hard about when/why I want to reference an Employee/Person/User, and I also wondered if there was a better way to do it.
I think it is just a common expected feature in collaboration apps to mention a person specifically because it can carry a little special behavior in some of them (notifications, assignment) and makes people quicker to access.
Yeah, this is ultimately the challenge I’m dealing with. I feel like the app templates should all have a generic People type, with possibly a User extension or something. If I create a “People” type to manage all people at the moment, then I lose the @ mentioning functionality, then end up with a confusing experience when adding People relationships to other Types. I also can’t manage this People app like all the other apps and can’t hide it. It seems to cause issues with sharing workspaces iirc because some of the User relations/data can’t be shared. To me, having a special flower like this is the product development equivalent to “Code Smell.”
The biggest thing for me is that I’m starting off without everyone in my organization using Fibery, like I’d assume most Product Teams might. I just want to be able to start using Fibery without the friction of worrying about who has licenses or not, how to setup relations to this other Person type that I have to create and relate to the Users type. I should be able to open a document, start taking notes, and reference people naturally. These people could then be stubbed out in the people area for later refinement without needing to worry if they are a User or not.
The benefit here being that there is less friction in referencing people, combined with those people already having information associated with them before they even open Fibery the first time.
Yeah, this is the same kind of thing I’m thinking through. The thing that sucks is that without inheritance you have to manage all the common fields manually. To me, it feels like an incomplete experience if everyone is going to have to go through this complicated decision-making before they can reference anyone in their organization. It also means that you need to think about the type of people they are to know how to reference them, which could change over time (someone is interviewed, then hired, then they leave the company).
FWIW, my Employees are those people that are (or ever have been) employed, and I have a collection of ‘Employment periods’ for each one that allows me to cope with them coming and going.
Also, the recently added ability to convert entities means that I can fairly easily have someone start working as an external ‘Person’, then become an ‘Employee’ without losing any history/traceability.
Most of that makes sense, even if I don’t see as strong a need as you. But I think something that might clarify the value for you is this: do you want to be able to tag “people” that are not yet users in the system such that if/when they do become users, they would then immediately have whatever consequences/benefits of “being tagged” the system provides? In other words Bob is not a user but you tag Bob, then you add Bob as a user a month later, and he has in his Activity Stream/Notifications that he was tagged, from the moment he joins? Is that one of the things you’re wanting?
It comes down to a conflict with the @mentioning. It is hard to think of an app quickly that doesn’t support that method of referencing people. I simply want to model the people in my domain and use @ for referencing them. I don’t care about Fibery user-specific functionality like activity feeds, etc. That is all stuff associated with a Fibery account, not People. I want to have a consistent way to reference and model people that may or may not have a fibery account. The people to other entities is the part I’m worried about.
I think this could end up much more messy than you expect in practice. I think it would be much more simple in onboarding new users if there was a consistent, ready to use people type that could be extended with functionality. For example, you could make a person an employee by associating an employee record kind of type, rather than converting between types. I do believe converting is needed, but it is something that is going to add complexity.
Huh, ok. I guess we just see it differently, because to me it actually makes a whole lot of intuitive sense that @ is for tagging people when you specifically, well, want to “at them”, i.e. ping them, notify them, get their attention. And thus intrinsically it connects with the user functionality and not just “people”. I don’t know of any other app that uses @ for people without that. So to me having a distinction between @'ing someone and linking them (with #) seems very sensible actually. The only situation in which having a distinction seems negative to me is if you ultimately might want someone to be able to get those @'s later on if/when they sign up, as I described above. But there is room for differing perspectives and needs here, of course.
Yeah, other apps do require accounts as well, but I suppose they have better free-level accounts. I do think Fibery needs to think differently since it is trying to be this generic domain modeling and process tool. After thinking about it as a basic use case, here is where I run into issues:
I’m a new product manager proving out the value of fibery to me and my organization with a Team plan
I start setting up some of my roadmap or issue backlog
I want to associate a person that may or may not be a direct collaborator of some kind in the future (ideally everyone would be in the org, but that might take some time)
That entity already has a relationship to the Users type, so I try to add a new user for that person
So, the issue I have here is that I cannot reference this person even via a regular relationship at this point without creating a new People type and setting up all the relations or by adding them as a paying User account which invites them. Even if I want to setup the new type, it gets really messy. This just doesn’t seem like a great experience for someone getting started.
I’d rather have time to set everything up ahead of time ready for the broader organizational use, then be able to trigger invites to people, pay for more licenses, etc. The licensing gets in the way of modeling, which is what I have a problem with. I’d be fine with requiring an email address as part of the People model as long as it doesn’t trigger the whole account creation process for that person until I’m ready for it.
That seems reasonable, but I don’t think they necessarily need to be separate Types to achieve that functionality. If you just consider how the rest of Fibery is built, the Users type just doesn’t fit the same pattern. A Type should be a basic Type and any custom behaviors are added via extensions. The extensions, as far as I know, don’t limit you from adding entities to that type. The Users type does. The problems I’m running into I believe wouldn’t exist if this architectural pattern was applied consistently.
After thinking about this discussion for a while, I tend to agree with you an elegant solution would be that ‘user’ is an extension (requiring an email address) available to any type, which adds the behaviours (permissions, notifications etc.).
@rothnic, this is a super interesting post and very much covers my pain from this similar issue:
Would love to get your take on that if you have a minute. In a nutshell, I am using Fibery to track recruiting, but don’t want to get stuck with two records for a person who starts as an entity in an HR app (that is a standard template provide by Fibery I should add - not made up by me), and then becomes a “user” when added with a license.
My feelings exactly. It is actually weird and awkward that users are represented as a type right now, IMO. The functionality that Fibery “users” brings - account association and @mentioning - seem more intuitively like “Extension” functionality to me.
This exactly why I was looking for this. As far as I can see there are two major things that People/User entities bring: ability to create notifications for them using @menion and also to use the assignment extension. The second one is most critical for me. This is exactly why I had asked the Fibery team previously about allowing “inactive” users a couple of months ago.
One of the main issues that I’ve seen with users adapting a new system is that often they need to start using the new system as well as add their content/import their information. I was hoping to build the system with a few key users, and once we had built out the main features and imported current data, then slowly enroll more people. That way, they first time they log in (or get a demo of the system), they already have notifications, mentions and assignments that they can work with.
In the absence of this feature, I’ve done exactly as @Chr1sG has done. I have created a “Contact Management” app with Contact entities that I basically use everywhere (e.g. they are attendees for meetings, assigned tasks, assigned projects, are stakeholders in projects, etc.). I have an Employee entity in the HR app, but they are also linked to the Contact entities so that I can keep employee information separate but at the same time I can get all the projects that are assigned to their Contact entity manifestation (my best attempt at modeling an owl:sameAs representation). I am currently using the name matching way of automatically linking the entities, but I think I will need to do this manually because sooner or later I’m going to have two contacts with the same name, one of whom could be an employee.
In my contact management app, I’ve also created Organization and Organizational Unit entities to better organize my contacts from various companies and departments. However, currently Fibery doesn’t really support the nesting ability to represent this (see this post). I think with large enough teams, this will eventually be a requirement for the User type too and a way of assigning permissions at a team/department level. Hopefully the UI will evolve to support this.
As far as I know, the User type can be configured just like other types (fields, buttons, extensions etc).
It is only the People app that behaves differently from other apps in that it only allows one type (User).
), but I think it’s worth taking a step back to more specifically define the elements that are wanted/needed here, not as they relate to any existing seemingly related implementation, and think about other ways to approach it that may be more congruent with how Fibery already works. So for example, as I mentioned above, there is a desire to “@ mention”, but what is the specific reason this is wanted? What capability do you hope to get from this possibility, and is there another, perhaps better way to handle it?