Need suggestions for app design & organizing data into types

Get Help
1

So I am trying to create a “Worker” app whose purpose is to store and report on various ‘human resource management’ data.

So right right away I create the Person type which contains very basic info about the worker: name, status, role, etc.

Then each worker person has a Contract so I create a type for that, but encounter the challenge for how to handle contracts that change over time (ex: pay increase from $30/hr to $40/hr). I want to retain the contract history so I can later run reports like: “How much did we pay this person between these dates?”

My current idea is for a Person have multiple Contracts, each with a start and end date, and then the most recent one be associated with the Person as the ‘active contract’ - but can I automatically associate this active contract with the Person? Or am I asking for too much?

The second part of my question is more about data organization: How do you decide when its time to create a new type?

So lets say I want to add info about the persons: skills, availability, location, etc. This is kind of data seems like it can be grouped into a Profile type. But is there any down side - in terms of unnecessary complexity - from separating data into types too early?

2 Likes
2

Hi, I recommend to add several Contracts to a Person then. If you want to have current rate, you can create a Current Rate formula for a Person and calculate it like this

Contracts.Filter(Active = True).Rate

Check formula reference for details Formulas Reference | Fibery Help Center

As for Types, it can be tricky. There are two common rules in my opinion:

  1. Strong: It represents a meaning and a separate “thing” in your process (it’s a noun we use in our communication, "let’s implement this Feature, let’s fix this Problem, etc)
  2. Weak: It has connections to more than one Type (if it has, most likely it should be a Type)

In your case, if you will link Profile to more than one Type, like to Person and Customer, it may be a good idea to create it. If it is just for a Person, then I’d not do it

3 Likes
3

It sounds as though skills might be suited to a multi-select field.

Not sure what availability could include, but it could be anything from a checkbox field, all the way up to a new type (with start and end date field and maybe hours per week integer field).

At the moment, fibery doesn’t support map/location fields, so you might have to just use a single-select for location.

Given that it is unlikely that multiple people have the same profile, it probably doesn’t warrant its own type.
You can e.g. configure views to see all entities with certain skills in a particular location who have availability.

2 Likes
4

Thanks, this was super helpful.

What about for something like an onboarding checklist? Say for each worker we have to do task A, task B, and task C.

Should we use Fibery for something like this since its kind of a temporary process? My first idea is to create a rich text “Onboarding” field and then add a checklist in there for each new worker.

5

Yeah, I’d suggest having a rich-text field but maybe set up an action button to prefill it with whatever standard instructions/checklist content you want.
When full automations are released (hopefully soon) you’ll be able to use an ‘on-entity-creation’ event instead of manual triggering (I assume).

1 Like
6

Totally agree with @Chr1sG here
You can add a Button, When clicking a button - a preset of Tasks will be generated.
Will that work for you?

1 Like
7

@Dimitri_S

Regarding:

Then each worker person has a Contract so I create a type for that, but encounter the challenge for how to handle contracts that change over time (ex: pay increase from $30/hr to $40/hr). I want to retain the contract history so I can later run reports like: “How much did we pay this person between these dates?”

In my mind, to really be able to answer your question, “How much did we pay this person between these dates?” you’d need an Invoice type.

You don’t pay contracts, you pay invoices. And I’m assuming in your situation, you’d have multiple invoices for any given contract. I could be wrong.

So what you’re wanting to do is create an instance of a Contract with a Person at any given point in time. That’s exactly what an Invoice type will do for you.

Then a Person has many Contracts and a Contract has many Invoices.

So on your Invoice type you could add additional entities for each invoice that comes in, which would have amounts payable listed on them as a field on the Invoice type. Right there you could see the hourly rate at that given point in time. You could then easily report on invoices for any given Contract or any given Person.

Rather than even creating a report, I’d recommend you create a formula on the Contract type that just calculates the total value of all Invoices associated with that contract. It’s nice to have it right there on the person’s contract entity when you open it. You always have that total invoiced at any moment in time when looking at any contract.

Then create a formula on the Person type that calculates the total value of all contracts associated with a person (add together all of those formula fields you just created on the Contract type).

That way, any time you are viewing any contract, you have the total value of all invoices associated with it right there. And any time you’re viewing a person, you have the total value of all invoices associated with that person right there also.

Hope that helps.

We have separate types for:

Contacts (your Person type)
Products (stuff we sell)
Orders
Line Items (many per order)
Payments

2 Likes
8

Nice tips :slight_smile:

Although it did strike me that it’s possible that when @Dimitri_S wrote

he meant “How much did we pay this person (per hour) between these dates?”

9

Oh okay @Chr1sG, quite possible.

Well if that was the intention, then I’d say if you start a new contract with each pay rate change, that works. No more types needed.

However, if a single contract has a changing hourly rate and you want that history to be reportable, then just create a Pay Rate type with a date field on it and a Contract can have many Pay Rates.

That should work.

1 Like