Template variables everywhere

Discussion in 'Feedback and suggestions' started by Phil R, Sep 28, 2016.

  1. Phil R

    Phil R Established Member

    As part of any migration, I am looking to see how we could make the customer experience more smooth and slick where possible.

    I have already made the suggestion that User / Org / Case form fields should be able to have a default. I would like to extend that significantly and suggest that the default should be capable of using template vars / placeholders.

    A simple scenario.

    I have an organisation field called "Product Version" (API product_version) that is a text box. Acme. Co. have this populated with "Funny App v1.7"

    I have a Case Form called "Funny App" for a specific product. This has a text Case Form Field assigned called "Product version".

    My image is that a default box is available for the field configuration, in which I populate "{{current_user.organization.custom_fields.product_version.value}}" (the immediate problem I spot is that current_user would only work correctly for a customer. But implementation is not my concern)

    This would pre-populate this for the customer, dynamically based on their account. Whilst re record the version they are on, this could be out of date or has the human factor of being changed for incorrect reasons. The purpose of the case form allows a extremely appropriate default to be seen when the customer loads the form.

    The goal of this suggestion would extend the concept further. After the above, a customer submits a case.

    Their Org profile stores "Funny App v1.7", but the customer submitted the case as "Funny App v1.8 alpha1". This is a mismatch and that's perfectly fine. It's information that helps us here and now, and allows us to make further decisions around this. Such as...

    I would then want a Automation as follows.

    Rule 1: "Cases: Form", "Eqaul to", "Funny App"
    Rule 2: "Cases: Product Version", "does not contain", "{{case.organization.custom_fields.product_version.value}}"
    Note: For Rule 2 to work best, we would want "equal to"

    Whatever is needed.

    The best example of an action is linked to my questions around notifications in the API.
    e.g. could we display a "Warning" that the version mismatches, without blocking operation, as a visual highlight on the state.
    Jamie Edwards likes this.

Share This Page