Power Automate Flow - Line breaks from dynamic content not carrying over (1 Viewer)

Isaac

Lifelong Learner
Local time
Today, 12:31
Joined
Mar 14, 2017
Messages
8,738
I had a Flow that sends an email, using Dynamic Content as the body of the email. The dynamic content was a Sharepoint list record's column value (Multi-line text). The dynamic content had line breaks in it but weren't carrying over to the email.

The solution was to be sure to click the code: </> icon in the Body of the email, and then clear out the small amount of code that was there, something like <p> </p> BEFORE adding the dynamic content. As long as I followed that procedure, now the line breaks show up as properly from the sharepoint multi line column.
 
  • Like
Reactions: Jon

Isaac

Lifelong Learner
Local time
Today, 12:31
Joined
Mar 14, 2017
Messages
8,738
Hi David,

I can't see that property or element in my Flow options, (I'm using the operation: Send an email from a shared mailbox (V2)

What does Nb mean?
 

cheekybuddha

AWF VIP
Local time
Today, 19:31
Joined
Jul 21, 2014
Messages
2,237
What does Nb mean?
Nota bene
I can't see that property or element in my Flow options
I can't see any properties or elements in your Flow options! ;)
the small amount of code that was there, something like <p> </p>
bit vague - posting exactly what you see would be helpful.

The <p></p> are HTML tags. They are for paragraphs. eg.
HTML:
<p>This will be</p><p>displayed split</p><p>over three lines</p>

I'm using the operation: Send an email from a shared mailbox (V2)
Either it's expecting HTML, and you need to convert your input, or there's a switch to format as plain text somewhere.
 

Isaac

Lifelong Learner
Local time
Today, 12:31
Joined
Mar 14, 2017
Messages
8,738
Ok, thanks for the tip on N.B. I learned something new today!
Please note that my original post included my solution as well. I am/will be posting tidbits (problems I encountered, and how I solved them) in this forum for the sole purpose of building up the searchable archives/information in our new Power Apps forum. If at any point Jon would rather I don't do this (following instead the tradition of only posting if you have an actual unsolved question), I'll be agreeable to the change, but for now I am trying to help get the content started. Hopefully this will drive traffic for people who have similar problems with Flows and come to AWF for solutions.

As for their usefulness, I was skeptical at first, too. Access macros are built into the front end application, and are limited by the typical constraints of user-driven interface events. Flows are really nothing like that: Flow operates at a much higher level - running on the server, with no user interaction needed, and perpetuating the permissions of the individual who set up the Flow. I would compare its usefulness to be more along the lines of SSIS, and in fact, it draws many parallels to SSIS, since you can essentially create packages that do many things, and can even hook into API's, .Net plugins, Web services, as well as all the standard things (update database records, administer permissions, maintenance, send notifications, etc).

Alternately, you can trigger a Flow from within a Power App, but so far my flows have been of type=Automated (based on a Trigger, of which there are 100's to choose from), or Scheduled (runs on a set schedule - every minute, hour, etc).

Currently I seem to be doing a lot more in Power Automate/Flow than I do in Power Apps. I haven't had a good case yet to use Power Apps, so have only so far created trivial test apps and taken all the tutorials as well as keeping up with content in the Microsoft forum.
Flows, on the other hand, is something I'm finding already quite useful in order to create server-hosted batch jobs, record updates, workflow triggering, notifications, etc.

My excitement is more along the lines of acceptance. My company has opened up the usage of Power Apps and Power Automate, so because of that, and believing that their use will drastically increase with time, I've decided to get involved earlier rather than later.
 

cheekybuddha

AWF VIP
Local time
Today, 19:31
Joined
Jul 21, 2014
Messages
2,237
Please note that my original post included my solution as well
Apologies - I misunderstood. I thought you had found a workaround, but were unhappy at leaving it as such.

I guess you lose the ability to format your email once you ditch the html.

I'm curious about whether multi-line text is actually stored in Sharepoint as html.
 

Isaac

Lifelong Learner
Local time
Today, 12:31
Joined
Mar 14, 2017
Messages
8,738
Yeah, I guess it's a trade-off. Leaving <p> </p> in there means that my Dynamic Content (inside those tags, apparently is where Flow puts it) loses all its formatting, and then, as you suggested, I'd probably have to go full-on HTML, which I definitely have no interest in doing.

The point of the Dynamic Content in this case is, it allows my business partners to have a configurable email body, so my goal was to get ALL of that benefit and suck it into the email, which now seems to be happening - at least for line breaks. I haven't experimented with much beyond that and don't have a need at the moment.
 

cheekybuddha

AWF VIP
Local time
Today, 19:31
Joined
Jul 21, 2014
Messages
2,237
The alternative would be the equivalent of VBA Replace() to handle the translation.

In VBA: Replace([YourTextField], vbNewLine, "<br>")

I guess these are the functions, though probably more like: Substitute([YourTextField], "\n", "<br>")
 
Last edited:

Isaac

Lifelong Learner
Local time
Today, 12:31
Joined
Mar 14, 2017
Messages
8,738
Thanks, I'll keep that in mind. The whole HTML aspect may well come up for me again and I may have to squarely face it.
 

Isaac

Lifelong Learner
Local time
Today, 12:31
Joined
Mar 14, 2017
Messages
8,738
I celebrated too hastily. The original solution only seemed to work the first time. Thereafter, each time I'd come back to my Flow Editor, the dynamic content previously displaying as EmailBody (a reference to my Sharepoint column EmailBody), was replaced with a dynamic content displayed as body/EmailBody, and the line breaks were ignored.

I have now solved the problem again by simply adding <br> as appropriate, into the actual text of the source (management-configurable) Sharepoint multi-line enhanced text column.

I also tried your method of replacing /n with <br> but it seemed to have no effect - but that's not to say you weren't on the right path, I just wasn't able to sort it that way (yet).

For now, I'm fairly content to just train management that, when configuring that option, go ahead and include <br> as appropriate - it's a very easy thing to train them on.

There may have been additional flow Operations I could have leveraged, such as HTMLCompose, but I'm not ready for that yet. :)
I will simply pass this on to the end user in this case and they can type their desired <br>'s....For now, that's as complicated as anyone wants it, anyway.

David, your various notes about HTML considerations have helped spark my necessary thought to continue working through this, so - thank you.
 

Isaac

Lifelong Learner
Local time
Today, 12:31
Joined
Mar 14, 2017
Messages
8,738
Actually your first conjecture was right, in a Power Automate Flow expression Replace is correct and works the same as Replace in VBA

1617722977141.png
 

Isaac

Lifelong Learner
Local time
Today, 12:31
Joined
Mar 14, 2017
Messages
8,738
Well, they are two different things after all. Even in SQL Server, you have Integration Services packages which can run Execute SQL tasks in T-SQL, but still has its own (weird) Expressions language. Which looks just enough similar to t-sql expressions to make you think the syntax is the same...until it's not.
 

Jbooker

New member
Local time
Today, 15:31
Joined
May 12, 2021
Messages
25
Check out Adaptive Cards and Actionable Emails if you want great looking emails from which recipients can efficiently perform useful actions.
 

Isaac

Lifelong Learner
Local time
Today, 12:31
Joined
Mar 14, 2017
Messages
8,738
I will jbooker, thanks. They look very useful! I like the Teams aspect of the first option ... since in my company, like many, Teams has become a full-blown epidemic :rolleyes:

My company is going through an enterprise-wide push to get all users on a certain cloud managed device; once that is complete, the integration with Teams and SPO will be complete - at which point the teams-centric operations will become super useful. Until then I have no guarantee that *all* my users will be using Teams, but eventually that will change.
 

Jbooker

New member
Local time
Today, 15:31
Joined
May 12, 2021
Messages
25
You can display most Adaptive Card info in Outlook Email Body as well. There are all kinds of Samples and a designer at adaptivecards.io
 

Isaac

Lifelong Learner
Local time
Today, 12:31
Joined
Mar 14, 2017
Messages
8,738
I've noticed that there is a big push toward "workflow" (or sometimes "approval" flow) type of processes that are so comprehensive and nuanced they may, in some cases, actually eliminate the need for a front end app altogether. I see the utilization of these techniques slowly representing a paradigm shift in thinking. For example I've realized that at my job we have at least 1 or more processes that, in the past, we maybe required end-users to open up an App designed specifically for collection of information--whether that be Access or just a well designed Sharepoint/Infopath/Sharepoint Designer FE GUI............Whereas really, we could probably automate the collection of this information through workflow processes now empowered by things like Teams and Flow. It feels weird to shift the thinking in this way at first for me, but I cannot deny the obvious improvement of data-collection techniques that just "show up" for the user in everyday places (like Teams or Outlook) and require no FE app to be opened at all.
 

Jbooker

New member
Local time
Today, 15:31
Joined
May 12, 2021
Messages
25
Same same. Meanwhile users just want it to open the FE and we be like...why exactly?

This will be the state of affairs for a long while for many companies.

Let's hope this paradigm and momentum remains long enough for adoption to catch up.
 

Users who are viewing this thread

Top Bottom