new line

It depends on where you are trying to have this output appear.  If, for example, you're showing it in a read-only paragraph field on an interface, you can simply insert a linebreak character ( char(10) ) anywhere you want a linebreak.  If your use case is something else, though, the answer is probably different.

I am trying to execute it on expression editor and by using char(10), the email is not printing on a new line.

you would need to switch expression editor's output to "Raw" mode to correctly see the linebreaks created by char(10).  That's why I specified a read-only Paragraph Field on an interface, as this would also display correctly there.

Switch to "<br/>" to apply line breaks in an email rendered as HTML.

Also I'm assuming your use of loggedinuser() is a placeholder, since this will not evaluate in the Send Email service as the system is performing the send, there is no user logged in at this time. 

concat(
  user(loggedInUser(),"firstName"),
  " ",
  user(loggedInUser(),"lastName"),
  "<br/>",
  "<br/>",
  user(loggedInUser(),"email")
)

Chris said:

this will not evaluate in the Send Email service

Except he didn't specify this was for output in an email.  I had to do a double-take at the comment "the email is not printing on a new line", but from the evidence I can gather, "the email" refers to the email address in the text output he initially describes, not an actual printed-out email.

Mike Schmitt said:

"the email" refers to the email address in the text output he initially describes, not an actual printed-out email

Ah, that could very well be the case.  We'll see (hopefully), at least we have all bases covered

..except maybe if there is a preference in Appian between:

char(10) - Line Feed

char(13) - Carriage Return

I had started with char(13) initially and have kept using it, since it works and the results are the same.  Maybe this is the new index() vs property() debate 

char(10) versus char(13) is a little more confusing IMHO.  to me the winner is char(10), as the use and the treatment of char(13) is highly inconsistent.  from what I've found over the years (and through the fuzzy memory filter a bit here), some elements return char(10) + char(13) when a line break is entered, and other places only insert a char(10).  in almost all cases that i've seen, char(13) is ignored upon rendering, at least in modern SAIL forms. 

AFAIK the last place I knew of where char(13) was added to input text was in the paragraph field component of the legacy tempo forms (*shudder*), and anyone who doesn't know what i'm referring to, count your blessings and keep on walkin' (trust me).

char(10) versus char(13) is a little more confusing IMHO.  to me the winner is char(10), as the use and the treatment of char(13) is highly inconsistent.  from what I've found over the years (and through the fuzzy memory filter a bit here), some elements return char(10) + char(13) when a line break is entered, and other places only insert a char(10).  in almost all cases that i've seen, char(13) is ignored upon rendering, at least in modern SAIL forms. 

AFAIK the last place I knew of where char(13) was added to input text was in the paragraph field component of the legacy tempo forms (*shudder*), and anyone who doesn't know what i'm referring to, count your blessings and keep on walkin' (trust me).

Mike Schmitt said:

AFAIK the last place I knew of where char(13) was added to input text was in the paragraph field component of the legacy tempo forms (*shudder*), and anyone who doesn't know what i'm referring to, count your blessings and keep on walkin' (trust me).

Haha, amen!!!

What did the old forms ever do for use .... except a javaScript auto-submit. What a traumatic experience that was! R.I.P