6 Replies Latest reply on Dec 8, 2015 8:51 AM by siplus

    Script and Calculation




      I have made a internal sales database for our company.


      On some records there is a "CallBackDate" - I want to make another field as a reminder called "Call Later" (with just 1 checkbox) so people can check this to remember to call the company back.


      The thing I need help with is that I want the "Call Later" field to become clear when the "CallBackDate" is changed.


      Any advise would be greatly appreciated.

        • 1. Re: Script and Calculation

          script trigger on CallBackDate, OnObjectSave, a script which clears the Call Later field:


          Set Field[Call Later; ""]

          Commit Records/Requests

          • 2. Re: Script and Calculation

            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.)


            Something like:


                 Case ( IsEmpty ( CallBackDate ) ; "" ; "" )

            • 3. Re: Script and Calculation

              Thank you so much.


              I've done exactly what you said and it's working

              • 4. Re: Script and Calculation

                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.

                • 5. Re: Script and Calculation

                  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.

                  • 6. Re: Script and Calculation

                    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.

                    Carl Jung


                    Business rules are just that, business rules.