Skip to main content

    Idea Pipeline

    Filter by idea status

    Filter by product area

    6164 Ideas

    dayn.johnson
    dayn.johnsonVIP ⭐️⭐️⭐️⭐️⭐️

    Dynamic JO needs additional data types if we are not allowed to do Custom Field Mapping.Released

    Title says it all. This issue (lack of Custom Field Mapping) was addressed in a post that’s hidden behind the private Dynamic JO beta group walls. It has not been solved, and it is (and will continue to be) a major pain point until a solution is implemented. @vmallya, is this something that’s on the roadmap to be re-released in dynamic JO, since the feature was present in advanced JO and was removed? Seems to be a pretty common use case.When building case fields in the dynamic JO, we’re only allowed to choose from three data types (number, boolean, string).   This becomes an issue when we then try to map those case fields to an email field in the template. Those fields (as strings) are only available in the name fields.  For comparison’s sake, in advanced JO, this was never an issue, since we were able to quickly map those strings to an email data type (or any other data type available in the Custom Field Mapping).  Would it be possible to add additional data types in the Dynamic JO Case Field Builder? This feels like we’re taking one step forward and two steps backward with this new release.The workaround (I’ll report back once I’ve tried it) will be to re-source the email data and merge it with the case field to turn those case data strings back into an email data type.* As a note, this workaround was presented in the aforementioned post that circulated in the private dynamic JO beta group (I’ll share the contents of that post in a comment below for reference), and the issue was marked as solved, but the fact that this is still such a big pain point (and that the feature was effectively hamstrung while working to improve the JO platform, even though it was addressed nine months ago) is concerning.Bottom line: creating a case expression to fix a null email so an email doesn’t fail should be easy.

    bradley
    bradleyExpert ⭐️

    Group Send Should Leverage Full Template BuilderNew Idea

    I’m trying out the Group Send feature, and one thing I don’t understand, is the template builder and why it is so incredibly basic. This is relevant if you want your users to create their own email templates and give them the permission. This is what the email template builder looks like in Group Send: Notice how on the right you only have one main header, Style. That has two formatting sub-headers: Dimension and Border and Background. This is what the email template builder looks like in the email template builder: Notice there is an additional “elements” header, and you have multiple ways to view the email itself. You can make much better looking emails in this version. Why are these experiences so vastly different? I don’t want to have to give CSMs permission to build and manage templates of every element of the platform for them to have the improved Email Template editor. Is there some setting I’m missing to enable this? I’m viewing this as a super admin so if it’s permissions based I should have it.Even if they did have access to the full builder, it would be a very disjointed experience to have to navigate from home, to email template builder, then back to home. This is yet another questionable UX experience. If my org is interested in having CSMs or other roles leverage this feature and wants them to be able to create their own templates for the biggest impact, the users should be able to easily use the advanced editing tools (that are in the main email template editor) to make decent looking emails and have some kind of hope of adhering to brand standards and guidelines.