# Need suggestions for app design & organizing data into types **URL:** \ **Category:** Get Help\ **Created:** [May 26, 2021, 11:20am UTC](https://community.fibery.io/t/need-suggestions-for-app-design-organizing-data-into-types/1656 "2021-05-26T11:20:40Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Dimitri\_S](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/dimitri_s/32/1683_2.png) [@Dimitri\_S](https://community.fibery.io/u/Dimitri_S)\ **Post date:** [May 26, 2021, 11:20am UTC](https://community.fibery.io/t/need-suggestions-for-app-design-organizing-data-into-types/1656/1 "2021-05-26T11:20:40Z")
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? ---
**Author:** ![mdubakov](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/mdubakov/32/10_2.png) [@mdubakov](https://community.fibery.io/u/mdubakov)\ **Post date:** [May 26, 2021, 11:47am UTC](https://community.fibery.io/t/need-suggestions-for-app-design-organizing-data-into-types/1656/2 "2021-05-26T11:47:57Z")
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 ```auto Contracts.Filter(Active = True).Rate ``` Check formula reference for details [Formulas Reference | Fibery Help Center](https://help.fibery.io/en/articles/3964093-formulas-reference) 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 ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [May 26, 2021, 12:03pm UTC](https://community.fibery.io/t/need-suggestions-for-app-design-organizing-data-into-types/1656/3 "2021-05-26T12:03:04Z")
> [@Dimitri\_S](#): > > So lets say I want to add info about the persons: skills, availability, location, etc. 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](https://community.fibery.io/t/suggestion-google-maps-integration-or-similar-map-view/1355) 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. ---
**Author:** ![Dimitri\_S](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/dimitri_s/32/1683_2.png) [@Dimitri\_S](https://community.fibery.io/u/Dimitri_S)\ **Post date:** [May 26, 2021, 7:32pm UTC](https://community.fibery.io/t/need-suggestions-for-app-design-organizing-data-into-types/1656/4 "2021-05-26T19:32:33Z")
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. ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [May 26, 2021, 7:56pm UTC](https://community.fibery.io/t/need-suggestions-for-app-design-organizing-data-into-types/1656/5 "2021-05-26T19:56:14Z")
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). ---
**Author:** ![Polina\_Zenevich](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/polina_zenevich/32/480_2.png) [@Polina\_Zenevich](https://community.fibery.io/u/Polina_Zenevich)\ **Post date:** [May 27, 2021, 3:07pm UTC](https://community.fibery.io/t/need-suggestions-for-app-design-organizing-data-into-types/1656/6 "2021-05-27T15:07:27Z")
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? ---
**Author:** ![webinit](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/webinit/32/5548_2.png) [@webinit](https://community.fibery.io/u/webinit)\ **Post date:** [June 2, 2021, 4:36am UTC](https://community.fibery.io/t/need-suggestions-for-app-design-organizing-data-into-types/1656/7 "2021-06-02T04:36:46Z")
@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 ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [June 2, 2021, 6:13am UTC](https://community.fibery.io/t/need-suggestions-for-app-design-organizing-data-into-types/1656/8 "2021-06-02T06:13:17Z")
Nice tips 🙂 Although it did strike me that it’s possible that when @Dimitri_S wrote > [@webinit](#): > > How much did we pay this person between these dates? he meant “How much did we pay this person (per hour) between these dates?” ---
**Author:** ![webinit](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/webinit/32/5548_2.png) [@webinit](https://community.fibery.io/u/webinit)\ **Post date:** [June 2, 2021, 6:52am UTC](https://community.fibery.io/t/need-suggestions-for-app-design-organizing-data-into-types/1656/9 "2021-06-02T06:52:37Z")
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.