script trigger on CallBackDate, OnObjectSave, a script which clears the Call Later field:
Set Field[Call Later; ""]
I would do this with an auto-enter calculation rather than a Script Trigger. That way, it's not layout dependent. (Unless that's what you want - that it only works when someone changes the date on that particular layout.)
Case ( IsEmpty ( CallBackDate ) ; "" ; "" )
Thank you so much.
I've done exactly what you said and it's working
Academically I can (and have no problem to) support your point, Mike.
But from a UX point of view, changing a value on a layout and having something behind the lines happening, something I'm not aware of, makes me uncomfortable. I'd prefer, in this case, having the 2 fields on the same layout, and a CF on the "Call Later" turning it to yellow to attract attention.
The question isn't merely academic. It's a question of business rule integrity.
If that field changes any other place, for any reason, your business rules aren't enforced. So if someone were to have a different layout with that field on it, or if you import records, or modify them with a script, then your trigger isn't going to fire, and your field doesn't get updated.
There's no negative impact on UX just because the field changed; that's a separate issue. Now, if you want to use Conditional Formatting to emphasize certain points or to make a smoother user experience, go crazy. But business rules like this shouldn't be vulnerable to changes elsewhere. They belong lower down than the interface level.
Just my $0.02.
data exists to serve us, not the other way around.
It all depends on how we look at things, and not how they are in themselves.
Business rules are just that, business rules.