How are Derived fields counted for dynamic rules?

Question

I wrote to customer support to see exactly how derived fields are counted (i reached my max...). They told me but upon testing I don't think they are right.

1. I believe a derive field is counted every time it is used in different rules. So if the same field is used in 4 rules, you have used up 4 of your derived fields count (this is contrary to what customer support states, but seems to happen in my testing). Can anyone confirm?
2. I believe it is counted in both conditions and actions, but am unclear, can anyone confirm?
3. I am not sure if it is counted in hide/show actions?

Has anyone tested and have a good idea of when/how derived fields are counted?

------------------------------
Mike Tamoush
------------------------------

blakeharrison · Answer

If you're reaching your limit of derived field usage in Form Rules, I'd suggest reconsidering how you've structured your form and why you've structured it this way. For example, can any of these rules can be replaced with Actions? Are any of these rules specific to certain User Roles and, if so, would building a different form for that Role make sense?

In my experience, hitting the limit on derived fields typically means that the form structure in your application is not optimized.

------------------------------
Blake Harrison
bharrison@datablender.io
DataBlender - Quickbase Solution Provider
Atlanta GA
404.800.1702 / http://datablender.io/
------------------------------

michaeltamoush · Answer

Blake,Indeed I am walking a fine line currently with needing to come up with a new structure. Most of my derived fields are being wasted in two areas. The main table I use that drives so much, is a Project Table. There are two distinct type of projects, and everything is identical in the projects, except the workflow it goes through. Both go through complicated, but different workflows. I lock things out and guide people for the workflows, but a lot of times these rules rely on what I call the 'Most Recent Status'. My workflow includes logged dropdown approval fields, so it shows the date any given person approved. A formula field extracts the most recent approval status. This formula field is now a derived field...So, I have 2 things happening.1. I hide/show a number of fields based on the type of project. This blasts through a lot of derived fields.2. I make read only a number of things in the workflow, which also eats up a lot of derived fields.I could make a second form for a different set of projects, but everyone is used to launching to the projects from a main table, so this already makes it tricky, let alone the whole idea of needing a specific edit button to put you in the right form, etc. I think it would be a nightmare and confusing.I could possibly make my workflow somehow make use of a related table? Use filters or something. Not sure, but I do need to stare at it for a while and figure something out.------------------------------Mike Tamoush------------------------------

blakeharrison · Answer

Using a logged field for the approval process might not be the best solution. Generally speaking, I structure this type of process in 1 of 2 ways.

For each Role / Person that must approve the record, create both an Approved By user field and an Approved Timestamp date/time field. You can then create a checkbox or button that would fill these fields based on Form Rules, Actions, or the API
Create a child table for Approvals, where each Role / Person would have what would essentially amount to an Approval Task. These would then have Assigned To, Status, Status Timestamp, Notes, etc.

Regarding the dual workflow for the Projects, I think keeping both workflows on the same form is probably the best option at this point. You're right in thinking that creating a 2nd form would be a nightmare, unless the workflow can be differentiated by Role, though it doesn't sound like that's the case. Another - even more complicated - option might be to split the workflow into 2 tables. I realize this seems counter-intuitive, but you would be able to completely separate things in this way. If I were to do that type of setup, I would make a copy of the Projects table and I would create a new table that would act as a Parent to both of the Projects tables, aggregating the information on the Projects and giving your users a single place to view Project info. You could then have a button for users to click that would open the correct record in the correct table in Edit. This isn't an ideal setup, but it's possible this might work for what you're trying to do.------------------------------Blake Harrisonbharrison@datablender.ioDataBlender - Quickbase Solution ProviderAtlanta GA404.800.1702 / http://datablender.io/------------------------------

markshnier__you · Answer

Mike, do you have any wasted derived fields where the rule is based on say [Parent Name] (a "derived" lookup field)&nbsp; when it could be based on [Related Customer] (not a lookup field) so not a derived field.------------------------------Mark Shnier (YQC)Quick Base Solution ProviderYour Quick Base Coachhttp://QuickBaseCoach.commark.shnier@gmail.com------------------------------

michaeltamoush · Answer

I think your original point of not using a logged field during the approval process, is one I wish I had the experience to realize 1.5 years ago. If I had to start over, I would probably lean towards a system like you state, using a button to fill other logged fields.However, now that the team is used to this system for the last year and a half, I stare at it every day wondering if today is the day I should completely change it....------------------------------Mike Tamoush------------------------------

Forum Discussion

How are Derived fields counted for dynamic rules?