Hey, Adam. Quick answers to your questions:

1. Yes, default text would be set in the parameters dialog just as defaults for other params are currently.

2. In our usage, the customer would change the value inside our application. Not sure how others use it, but from our end it would be done exactly the same as they do currently for the other variable types.

3. The value passed back from our side would be a regular string of text. I believe but cannot guarantee (because I'm not involved in the actual integration side of things) that newlines would be denoted in the standard \n format. If users wanted to add formatting and the template were designed to accept it (e.g. the Out tag would have the TEMPLATE type assigned), they'd have to enter the raw HTML code themselves, which should look and be handled like any other string of text as far as you're concerned.

Hope that's enough info. If not, let me know here or reach out to me directly and I can connect you with someone at our end with more technical knowledge about the actual integration.

Hi Brent!

I had posted comments on this ticket, but it appears they were not showing up for some reason!

We are writing requirements for this request and I want to be sure we are understanding it correctly. Could you please clarify these questions:
1. The multi-paragraph default block of text you are referencing is set in designer Input Parameters dialog?
2. Where does the customer customize this default block of text? When running a report from the designer, or maybe in your application?
3. If you are passing a value associated to the input parameter in the engine, what is the format of the multi-paragraph text you are passing in? HTML, String, other? The reason I ask is to understand how your paragraphs and newlines are defined.

We are trying to determine how we can implement this functionality both to solve your use case, but also to provide the maximum value to other customers as well.

Thank you for your clarifications and patience,
Adam Austin
Product Manager

Matthew -- we use a similar method to output HTML-formatted text that comes directly from data and briefly discussed doing this also with params as you described, but we won't ask our users to add HTML tags to get line breaks and have a different approach within our solution. But it's good for others to know this workaround until this idea is implemented. :)

Kelly Gillespie (Windward Support) just showed me a trick... Input parameter type text, pass in HTML. Use "out" tag and set it's type to "Template". I'm only using this to format address blocks, but should work for larger strings.

They would be input parameters, yes. Ideal workflow would be to set a default block of multi-paragraph text that the user could then customize as s/he sees fit (or replace altogether). The user would be able to see several lines of text and expand the box as needed (using existing web browser capabilities) to see more if needed. This is a common request from our customers, and we have to use other functionality in our own application to work around it, which means we end up not using the Windward input parameters at all so as to not split up where they're entering data.

Just a quick comment that 3.5 years later, this is still an issue I'm having to work around as recently as today for a new customer. It's embarrassing to say that we still aren't able to support multi-paragraph text variables. :(

In answer to your question, Adam, the text is plain text. Line breaks in the text returned could be via the newline character as you mentioned, as long as the user doesn't need to manually type \n.

Hi Brent!

Question for you: What form are these text bodies in as they are submitted to the template? Are they coming in as data, or input parameters? Also, how is your new line defined, are you utilizing the "\n" newline character in your data or something else?

Thank you for your patience in helping me understand your request.

Adam Austin
Product Manager

I should have said that this isn't possible without multiple variables, one per paragraph, which isn't an acceptable solution for my users.