I have installed the Hiring App, and one thing I noticed unique to this app vs. other is that the Candidate Type has a unique handling that looks to be similar to that of Users in Fibery. There is this special Avatar area:
…and it would appear this type of record is similar to the ones Users have in the “People” App, which is also something I’ve wondered about as there are a lot of self-generating relations in there, and Users don’t have Highlights in their Entities, to name another unique aspect of them.
We are now moving full on in Fibery, and tracking Candidates we are going to hire. It would be super helpful to be able to convert those into actual users once they are brought into Fibery. One issue with not having this ability is we now will reference a Candidate quite a bit with highlights as they move through interviews, tests, etc. prior to hire. But once hired, we then have that candidate in Fibery as a user, and we start to get duplication. I don’t want to in turn outright delete the Candidate Entity because we then lose valuable data. But without this merge, or “conversion” of a hired Candidate Type into a User Type, I’m not sure how to solve this problem or workaround it. So if I hire say 10 people in the next year using Fibery, I’ll have 10 of these odd Entities kicking around of both Users and Candidates who are the same people.
If you guys can set up to merge or convert these records somehow, that would be super useful I would imagine for all teams that buy Fibery, use it for hiring, and then those hires become Users in their Fibery instances. So please consider this as it’s a problem is going to persist if people actually start using Fibery through the years as you hope they will!
Avatar Area is an Avatar Extension, you are free to add anywhere.
It would be super helpful to be able to convert those into actual users once they are brought into Fibery.
You can just add a relation between Candidate and User - then you will see all the things you need.
I am not sure that the User and Candidate have to have the same info.
Could you please provide examples, which info will be duplicated?
For now we can’t convert Types - from one to another (although have that in the future plans). Your request is even more unique - convert Type (Entity) into Human (User).
Not sure we will handle that case, but noted your case anyway.
OK, thanks for the response. What you are suggesting here:
Is not exactly useful, because I’m talking about using Fibery to recruit new hires. In that case, the “Candidate” is going to become the “User” once they are hired. The Email, phone #, CV, etc. are going to be the same. So linking doesn’t help as I still wind up with two records for the same person. This leads to having confusion when you search because “John Smith” will come up 2x. My team is already dealing with this and we plan to continue to track hiring in Fibery in the next few months of several more (at least) new staff who will also join Fibery.
I’m not sure how much work it would really be on the backend, but if over time you set up for this simple ability to Convert this Type into a User - given the special way User’s are handled in Fibery - it will help any number of teams who would like to use Fibery to recruit, then hire, staff. They will all be left with this same issue as I’m having, unless there is another solution I didn’t think of? What I don’t want to do is delete the Candidate record when somebody his hires, as that is a lot of valuable data lost.
How do you guys handle this internally as I assume you also are using Fibery for your own Recruitment needs?
You’ll probably hate me for saying this, but have you thought about just using an Action Button?
You could have a button for Candidates (called “Hired!”) which when pressed, will create a User and transfers the necessary info from the Candidate (name, email address, phone # etc.).
The button could also trigger other things (like assigning the person to training, or arranging that they get sent a welcome bunch of flowers, or whatever )
You can also use the button to add the relationship between the Candidate entity and the User entity so that you can always look back at what info was recorded during the recruitment process.
Similarly, you might want a button (called “Didn’t make it”) which ensures that sensitive information on candidates who didn’t join the team gets deleted (for GDPR compliance or whatever) or maybe adds a time stamp so that these things can become flagged as due after a pre-determined period of time.
FWIW, I have an Employee type that isn’t the same as the User type, since some employees might never end up using Fibery, but I still want to be able to record various details related to employment.
i.e. all Users are Employees, but not all Employees are Users
Chris, always appreciate your help, and humility . There are a few other suggestions of yours I have not gotten back to but I intend to try to implement as I move along in Fibery.
One question here - I was not aware you could “create” a User? I thought that area of Fibery was more strictly controlled and relied on the Workspace settings.
I will try your solutions, thanks again. However, my point remains that over time, if you use the HR app in Fibery to hire, you are going to one way or another have duplicate entities of the same person on your team if they are first a Candidate, then become a User. I worry about Entity proliferation as an Instance grows, and I think it would be useful if, say down the road when the team looks to some more advanced, edge-case releases, this might get addressed. My hope in posting is that others who will have this issue over time, will find this useful. I’m not sure how hard of an implementation this is, either, but I had thought it wasn’t too ambitious.
This would again be a real differentiator. I am not aware of any app out there that would allow you to track your recruitment, then seamlessly convert candidates out of that process into actual users of the system used to recruit them!
It’s definitely possible
I managed with the code below to create a new user, and it would only require a few mods to make it so that the user is created with values taken from the Candidate entity.
I should have added, you can of course also delete the Candidate entity after you have created the User
To be honest, this is kind of related to the request that has come up on this forum to change an entity type. I imagine that you could write some code that duplicates an entity of one type as another type (with appropriate checking for which fields can be transferred) and then deletes the original entity.
All suggestions along these lines imply breaking all existing links to the original entity.
Entities should have stable unique context-independent IDs.
Breaking links to entities (e.g. because they’ve been converted to another type or their type has been renamed etc) is a cardinal sin.
Trello does this very well. In the context of a board a shortened version of the id can be used, but the full id is globally unique and is all that’s needed to link to any card, no matter where it’s moved or how it’s changed.
There should be only Entities. Login should be an Extension that you can add to any Type.
Type should be just a peg to hang a name and fields and extensions for new Entities created using that type. When an entity changes to a different type, existing fields may be shadowed if they aren’t present on the new type and aren’t migrated. That’s OK.
Internally, Fields should be objects referenced from the entity, they shouldn’t be part of it.
The more the system is consistent (everything is an entity, including users), the more powerful it becomes. This is the reason for the existence of Fibery (any app can be described using entities and their fields and references). The same goes for Fibery itself: don’t build exceptions into Fibery (e.g. User is a special kind of thing that is not an Entity) that cause the kind of contortions described in this thread. Don’t force re-creation of Entities that represent the same thing under any circumstances: that is letting a technical issue leak into the application domain causing pain for end users, e.g. breaking hyperlinks and field references.
I know that a lot of people on this forum come from SW/computer/data science background, but I imagine that the average user doesn’t actually care about unique, context-independent IDs. They care about the functionality that is available rather than how it is achieved ‘under the hood’.
Of course, you might be right that using unique, enduring IDs is a good technical solution
Ah but these IDs show up in URLs and thus prevent hyperlinks from external systems and docs from breaking. The average user very much cares about that.
