The out data type here is limited to number, string and boolean. But we have encountered multiple usecases where the final out put fields needs to a date based on set of conditions/criteria.
Is this something in road map?
This ability to have date type in the case statements is not a possibility in Data Designer also.
If we can have the ability then it would be super helpful
If you ever had a profile with us, there's no need to create another one.
Don't worry if your email address has since changed, or you can't remember your login, just let us know at community@gainsight.com and we'll help you get started from where you left.
Else, please continue with the registration below.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Hi@shivani
This is a good idea. Can you also add some usecases that you might want to accomplish with case and dates?
Company has sales orders and change orders to the original sales order. Sales order always has a service start and service end dates. Change order should have the same but not always depending on the reason for the change order.
If I’m pulling products out of the change order and need to have the service start and end date then the logic would be:
If change order service start date is null
then sales order service start date
else change order service start date
Same for service end date
Here is another use case. I’m trying to unify 2 data sets in rules, and I need to aggregate a date field. If one dataset has null value in the date field, then I want to use the date from the other dataset so that the result is a single date field to be inserted in a custom object.
NVL or coalesce would be great to have too. It would solve for this use case.
At the moment I’m having the same issue, my use case is the same as above.
Absolutely required, why is it not a thing yet?
Here is another use case. I’m trying to unify 2 data sets in rules, and I need to aggregate a date field. If one dataset has null value in the date field, then I want to use the date from the other dataset so that the result is a single date field to be inserted in a custom object.
NVL or coalesce would be great to have too. It would solve for this use case.
This is a persistent scenario we run in to (wanting to consolidate two or more different Date Fields into a single Date Field) and was hoping to see a new Date field type for Case Fields in the new Horizon Rule Designer.
In order to accomplish this today, I need to split off multiple Transforms that filter in just the filled Date field, renaming their output Date field identically in the Transforms so that I can Union each set back together and then Merge the new consolidated Date field back in to the master dataset. Multiple Tasks could be easily solved in one Transform, with far better logic management and control.
I have a similar use case, trying to simply actions / steps in a rule chain. Either requires more transformations, or more actions. If I could use a case statement and choose a date field across multiple fields, then I could choose the right one for each relationship, and have a single field, which would allow a single action.
This is not the right answer. But, a workaround I’ve done for when we want to fill in a date where one is greater than the other.
In gets the job done. But does require more steps. Should be able to output in date still.
Wayne, that is a good workaround for other use cases, but I am trying to standardize a rule across all my relationships (products). I have one MDA object that stores all my product line item SKUs along with Account ID, each with different Term end dates.
Pivoting off a SKU category allows me to easily create a date Max end date field for each product. From there I can simply merge with the relationship off the Account ID. If I could do a case statement on the Relationship Name (all or relationship names are consistent and named “<<Product Name>>” then I could build out a case statement to determine which field date I should populate the relationship with dynamically and it’s simply one action step, not 1 for every product I have.
Without this, the rule doesn’t scale well as more products are added, more actions / steps are needed.