I am creating a due date field where i want to provide due date for each option which is present in multiselect field.
I believe there are two options to achieve this:
PREFERRED OPTION: you could convert the multiselect field to a linked record field and create another table with all the records you are linking to. This table should contain the options of the multiselect as names of the records and the due dates as date fields of the records. You would then be able to use lookup fields on these records to pull in the due date. This is I believe the best approach because you can then expand these multiselect records to contain many more fields, according to your needs. You can also perform other aggregate operations such as count the number of times the multiselect fields appear dynamically, rollup the values of these fields and much more.
SIMPLE WORKAROUND: you could have a formula which checks the option in the multiselect field and through some conditional logic adds the relevant due dates. This is as mentioned a quick workaround and I would only use it if you have 2/3 multiselect options or else your formula becomes very long and hard to manage
Hope this helps!
Thanks, But my goal is different here.
I have multiple project which is shared by more than one freelancer. Now each project has some task which i am selecting in multiselect field as there are more than one task.
I can give multiple task to freelancer and each task has different due date. Can this be in a single field and dates are arranged based on priority basis. Task whose due date is first, should come first .
I believe you should structure your base differently and have another table called tasks which contains one record for each task.
You can then link each task to a project and then have a view where you group by projects and sort by task due dates to see the tasks in an organised, sorted way.
Hope this helps!
Yeah, You are right.
I think this problem is occurring due to the primary column client name, gonna explain to you in brief.
My first field is client name and then articles field, meaning there are 8 articles each for different clients and each 8 articles are different for each client and they are assigned to freelancers.
For example client 1 has 8 articles and are distributed to different freelancers such as 2 articles to freelancer 1, another 2 articles to another freelancer and so on.
Then the problem of due dates comes into picture. I hope you understand.
got it, thanks for clarifying. Yes, then I believe the best approach is to have a separate table called Articles that matches each Freelancer/Project with a specific article. To improve the structure of the base (especially if you scale over 5 projects), I would also suggest having two additional separate tables (one for Freelancers and one for clients) and keeping this PFMS table as the projects table
This topic was solved and automatically closed 15 days after the last reply. New replies are no longer allowed.