BPM date fields

Hi Leaya, I agree with Ben regarding potential problems.

User laziness to not update that a meeting was held should not be tolerated, mainly because that would also imply users didn't also update the notes or the meeting outcome which sometimes could warrant another action.

I would suggest adding the 'Planned activities' dashlet to their main dashboard so they can see overdue Meetings and Calls so they can address quickly with simply click to either close as held, cancel, or go to the outstanding record to update everything.

I actually know how to achieve what you want but thought I'd try and get you to evaluate the advice for best practice first.
Hope you're not offended

Vincent Amari is definitely right!

Although I have to say, that the prebuilt Planned Activities Dashlet at least for us is rather useless, since it doesn't display any other helpful information for the user (if they don't put it in the subject line of each activity (like the customer's company name or customer number for example). So, we are always using a Listview-Dashlet for these puposes - with all the downsides that brings along (not being able, to share it easily, if it has a more specific filter for example).

hi Julia Weinhold

You can automate the naming of the subject line to be more useful

hi Julia Weinhold

You can automate the naming of the subject line to be more useful

Hi Tony Romano,

of course we could - either through studio and Sugar Logic or through BPM.

But that means knowingly duplicating information that is already there, just because yet another a standard feature of Sugar isn't well enough designed and thought through. Often enough we have to cover shortfalls of the system like this e.g. to be able to use information from related modules in BPM process definitions or email templates. And our developer is shaking his head each and every time because that means yet another field with redundant information that we have to include in our scripts to anonymize our test environments etc.

And I'm beginning to think that this can't be the go-to solution anymore.

Hi Julia Weinhold,

I regret that I have to agree with you on a significant part of your reply. For a no code platform, Suagr does require a lot of development to make it productive in highly demanding contexts. 

This being said, I've taken to creating support tickets to ask for enhancements. I have to say that this has not yielded significant improvements (yet), but at least I've transormed my disapointment into something productive. 

Also if we don't share our feedback in a structured and traceable way, SugarCRM can always say that there are no issues (I've heard that in the past).

Finally, keep in mind that Sugar is much better than some platforms I've seen, and that some of the other big names out there also have their shortcomings. Of course, the more expensive solutions are better, the question always being does this generate a better ROI for the customer? 

Hi Damien Pochon,

I totally agree with Sugar being a good platform and we have absolutely no desire to switch. My last sentence was more related to the "copying-information-to-automate-stuff"-problem ;)

I really appreciate all the possibilities the system gives us and Sugar has really been cleaning up and improving a lot lately - especially in Studio. But that makes all the problems and bugs (partly with a lot of impact on the usability and data consistency) that haven't been addressed in years even more frustrating. I desperately want this system to work, because I truly believe in it and its potential! But ever so often I think: "Wow, great new feature, have been waiting years for this!" and when I try it, I find that it has not been thought through until the end (best example: filter sharing on dashboards). I mean, I can totally relate because it's often the same with us, but that doesn't make it any better.

Since last year we are in fact creating support cases for every bug and enhancement request we have, because just like you I found (especially in comparison to the previous community-forum) that only then a problem has at least a chance to get handled officially. Even if for the most part that chance is pretty small, from what I've seen and experienced so far (which you seem to have, too). And the thing is: testing, reproducing, thoroughly reporting and sometimes even fixing problems of the software itself is not our main job and it takes a lot of time. Not only upfront to create the case but also sometimes afterwards until the problem is correctly understood by support - not even to mention a possible fix. And if you invest all this time and then still nothing is happening for years (and I regularly find bug-tickets for problems that afect us that have been open since 2016/17 or longer), you start to question why you should continue investing this time and effort in bug reporting etc. And this also can't be what Sugar wants.

But I guess we're kind of digressing from the initial problem of this thread ;-)

hi Julia Weinhold

it was only a suggestion as I didn't wish to assume you knew, as it's a very comon method to help make subject lines both consistant and help users from having to think

It's no more dupliaction as example the 'Full Name' which is sometimes more convenient that seperate Firstname Lastname.

I fully agree :)

Hi Tony Romano,

of course, I totally got that! :)

It's just that we have been doing stuff like that so often, and have like 20 different places in the system, where we are automatically creating names or copying information from one field and module to another etc. and I just don't see, why I should be adding even more to this list (it has to stay manageable, in the end) just to be able to use this, sorry, but quite poorly designed dashlet (and regarding there is a solid, yet definitely not great workaround with the list view dashlet).