You are viewing limited content. For full access, please sign in.

Discussion

Discussion

[FEATURE REQUEST] - Cloud Look-up Tables Null Values

Laserfiche Cloud
Updated November 12
posted on October 24, 2024

In Cloud Look-up tables you can't use Rules to insert null values for the following data types (and possibly others?):

  • Date/Time
  • Numeric
  • Integer

You either have to use a default value (like a default date/time, or a '0'), or change your data type to text - and both workarounds have knock-on implications for things like reporting or rules and workflows used later on.

This is especially important now that we are using the OData Look-up Table API for things like Power BI. Using a text data-type for things like dates causes at the very least lots of additional formatting and data manipulation at the Power BI end.

Further, there are times when it is important for the data to have a Null value, because that represents something for workflow or process conditions (i.e. that no follow-up to a process has been planned; that no GST/tax is present for an invoice etc etc, and it needs to be blank instead of a '0.00').

It also means that some workflow calculations need further workarounds (e.g. adding days or hours to date values that are seen as 'text' can be problematic).

Is there actually a way to 'Allow Nulls' like there would be in a SQL DB?

If not - could we please add this as functionality.

8 0
replied on November 11

It’s really frustrating that the update logic behaves inconsistently. For string fields, leaving a value unmapped simply skips the update, which makes sense when nothing has changed. But for date fields, the system forces us to enter a date even if the value hasn’t changed, otherwise it throws an error. This is not just annoying—it’s counterproductive, because there are plenty of cases where you genuinely don’t want to update a date, and being forced to provide a new value creates unnecessary work and increases the risk of mistakes. The inconsistency between field types makes workflows harder to manage and less intuitive.

In practice, this inconsistency forces us to write separate rules just to set dates, even when nothing has actually changed. A workflow might need to run three or four rules on the same table just to avoid CAST errors. That quickly leads to a huge number of rules, which are difficult to manage and keep track of, making workflows more complex and error-prone.

2 0
replied on November 12

Fully agree. 

0 0
replied on October 17

Yes, i have a scenario where i'm tracking regulatory dates. Upon submit i set a date of +20 days to deem the application is complete. If the item is found to be not complete it goes back to the applicant and the time must be reset when they respond however, in Cloud it is impossible to remove the original date, i can't set it to "blank" using a rule, instead all we can do is set a future date like 9999-01-01.

2 0
replied on October 27

Yes, we do something similar; we typically use 0001-01-01T00:00:00Z and then have that excluded from look-ups etc.

2 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...