We are updating the data type for four deals-related response fields from datetime to date.
Effective from: December 6, 2023
See the full post in our Changelog
1 Like
Does this change mean that we lose the actual time portion of the won time?
Will there be additional fields to get the time part back?
Why are you making this change?
Thanks in advance!
Samir
1 Like
Does this affect somehow with sorting capability of a /deals endpoint with usage of sort=close_time+DESC query param?
Like @dev_autonl said, we’d like to keep the time portion of a value too since we’re synchronizing data always a few hours back and this can potentially increase number of API calls towards you. Usage of webhooks is on our roadmap but it’ll not be finalized as soon as expected.
Thanks.
Any specific reason for removing the time information?
@dev_autonl @buri_nr @jp-apps apologies for coming back to you with such a delay!
Here are answers to your questions:
Does this change mean that we lose the actual time portion of the won time?
Will there be additional fields to get the time part back?
Yes, the time portion of the datetime will be lost and we do not plan adding any fields to get it back.
Why are you making this change?
To solve an issue where different team members could see deal being won in different days depending on which timezone they’re in.
The deal won/lost reporting is usually viewed on a monthly timeframe, less frequently on a weekly timeframe and rarely on a daily timeframe.
So the assumption is that removing this extra precision won’t cause issues for the vast majority of users. Happy to hear if you have use cases where it’s needed.
Does this affect somehow with sorting capability of a
/dealsendpoint with usage ofsort=close_time+DESCquery param?
Like @dev_autonl said, we’d like to keep the time portion of a value too since we’re synchronizing data always a few hours back and this can potentially increase number of API calls towards you. Usage of webhooks is on our roadmap but it’ll not be finalized as soon as expected.
What is the exact API call you are sending @buri_nr? It might affect it.
Anyway, for the use case of syncing data, I recommend using the /deals/collection endpoint. It operates much faster and supports the since parameter that operates with seconds. And more importantly it operates on the update_time field not close_time. The update_time is better to use when syncing data because close_time will obviously not be updated when something si changed on a deal that isn’t winning/closing it.
Just received a mail about that change. Are you seriously changing the fields that say “close_TIME”, “won_TIME”, “first_won_TIME”, “lost_TIME” to no longer contain the - well - TIME?
What alternatives do I have to see at which time of a day deals have been lost?
To solve an issue where different team members could see deal being won in different days depending on which timezone they’re in.
How is this an issue (well, if you understand timezones at least)? Now you are making it even more confusing. If a team member in Sydney (UTC+10) marks a deal as won, another team member in Vancouver (UTC-8) will see the deal as won in the future?
2 Likes
To confirm, will the time portion also be lost for previously won deals? If I wanted to keep that would I now have to keep a custom datetime field for that?
My organization cares a lot about the day and time a deal is won as we pay out commissions and bonuses based off of the date a deal is won in the reps timezone.Using the Sydney <> Vancouver example above, if we lose the time precision we have no idea which date the deal was actually won and which month to count the won deal in towards sales floors.
1 Like
Hello! @sebastiank and @Bryan_Rogers
I got some answers from the team who checked your questions:
What alternatives do I have to see at which time of a day deals have been lost?
There are no current alternatives after the field type has been changed. We will look into it if we can offer a way to get the information.
How is this an issue (well, if you understand timezones at least)? Now you are making it even more confusing. If a team member in Sydney (UTC+10) marks a deal as won, another team member in Vancouver (UTC-8) will see the deal as won in the future?
Indeed, with this new change there can be temporary inconsistencies. After some time passes all the users will see the same dates. With Datetime field there were permanent inconsistencies for many users. There is no one solution fits all for this issue.
To confirm, will the time portion also be lost for previously won deals? If I wanted to keep that would I now have to keep a custom datetime field for that?
Yes, it will also affect the previously won deals. Time value will be removed for all deals.
Thanks for the response. It would be very helpful if we could get an alternative way to receive the actual time a deal was won/lost. We do a lot of B2C and use it to monitor what time of day is most likely to convert different customer groups.
Short term it looks like we must use webhooks and store the data ourselves.
Again, thanks for the prompt response.
So if we win a deal one minute before or after midnight in a +1 or -1 hour timezone, what day will pipedrive report the deal being won on?
I don’t see how making the time resolution less will help with the actual issue at hand? The actual time zone will still matter when trying to calculate the day that a deal was won or lost.
In one time zone the deal was won in the previous day, and in another time zone the deal was won in the next day.. This is the expected behaviour! The time zone for where the report should be made affects the results of the report. This is the problem that UTC and timezones fixes.
Without the exact time and timezone it is now impossible to actually create correct reporting, where previously it was possible to do.
What timezone will be used by pipedrive when determining the day the deal was won?
And how will we correct the deals that will now be reported on the wrong day because of time zone differences?
As I read these changes, it not only breaks the API, it also introduces reporting errors that can’t be fixed by the end users.
Previously there were only errors in the Pipedrive UI? now there will be errors in the Pipedrive UI and everywhere else for deals won in the day overlap in different timezones.
Please explain how this breaking API change solves the issue you are saying it will solve, and how we as end users should do to get correct reporting on deals won at the start/end of days in a different timezone?
3 Likes
Hi,
I agree that changing this will be a big issue for us as well.
1 Like
I totally agree with everyone on this thread. I really don’t understand how this could help solve a problem. Removing the time of the signature can create a lot more problems for our customers :
-
Impossible to see the order in which deals were signed. For progressive projects this is an issue.
-
For customers with SLA that includes maximum delay to deliver a service, this can become a problem where we need to know the time of a signature.
-
We have customers with Dashboards that needs to identify what was the first deal signed for a specific customer. This won’t be possible for a customer with 2 deals signed on the same day.
I think that if you remove the actual time from your date field, you will at a minimum need to add a time field that users will have the choice to use or not. But totally removing the time is in my opinion a deal breaker for many customers. In our case we can identify at least 5 businesses that relies on time for their operation…
Please reconsider this. I see a lot of upcoming problems from that decision.
4 Likes
Thanks everyone for your feedback.
We have decided not to proceed with the breaking change set for December 6, 2023.
After reviewing your feedback, we decided that the proposed changes would create too much burden on our customers. As such, we’ll be keeping the current API behavior intact.
Official comms will come soon.
For those who have already started making adjustments, we truly appreciate your efforts. Since we are not moving forward with the changes, please revert any code updates you’ve made in response to the initial announcement.
We apologize for any inconvenience this may have caused and we thank you for your understanding.