We would need to know some more about what all of you want NOW() for. The only reason mentioned here is to display the current time to a user in the user interface. If that is all that is needed it would be better to have a specific UI widget for that. The dashboard only communicates with the data in the model when a user interacts with it, so if it were a cell in a grid showing the result of a NOW function then it would only update when the user interacted.
I suspect that there are other reasons for having a NOW function, and knowing what they are will help in the design. One question that immediately springs to mind is at what granularity should a NOW function change the results it returns. Should it be seconds, minutes, hours? Another is timezone. All Anaplan models run on machines where the clock is set to UTC (Standard time in London). However some models are for users in a different timezone (e.g. Pacific) and some are for users spread across multiple timezones. What would people need? Any variation in this respect would have to be specified in parameters to the function. This is not like Excel where it is on a particular user's machine where the timezone is picked up from the user's operating system.
The granularity is also significant when considering recalculation. When your dashboard reads from the Anaplan model, the server applies any cell updates and then recalculates those cells of the model that have changed as a result. For a model in which there is little data-entry this recalculation will be insignificant and performance will be good. If a NOW function was ticking over every second then the model would need to be updated on every interaction. The performance impact of this would need to be considered. We are currently working on the TODAY function which has a number of similar questions. However the granularity of change of TODAY is much less and so the performance impact will be minimal.
@duncan_pearson For the cases I have, only Today() function will be relevant, for my use cases NOW() is not needed. Not sure in what (planning) use cases we need to have NOW()
As for the mentioned use case in the beginning of this thread, perhaps it is better to be able to use the logging data and have a function to display part of the logging information.
The ability to garner a current date or date time is critical functionality in any project and most use cases. I may not be speaking for the entirety of the community, but Im guessing a sizable percentage of the modelers care less about the how and more about the function. With performance considerations (of course) any viable method to pull the current date and/or date time would be a drastic improvement over what is available today and something that allows us to get this information directly from the system without additional build means we're focused on delivering results as opposed to spending time and effort to produce this data.
- input a date or timestamp in items created through actions without going through users inputing a date / time
- testing a date as a cutoff to cumulate amounts up to a specific date. We can sometimes have data with forward due dates that calculations are required to exclude.
An option would be to allow in a now() function to allow a frequency update (dayly, hourly...) parameter to be passed as a parameter to allow action to recalculate at a defined frequency ?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
