Questions Regarding Split and Count Functions

Hi guys, we've been trying to use Split and Count functions in manipulating the information in the Email.Message.Body variable in order for it to be usable through looped data table checks however we have some questions regarding the said functions:

  • How do you define carriage return as a delimiter for Split? Could you have multiple delimiters on a single instance of Split?
  • Count has been returning odd numbers that doesn't make sense, for example we only have 3 words in our test email body but the corresponding Count output came out 109, single/no words came up as 107. Is this the expected result or are we doing something wrong?

Here is a sample of what were trying to do:

Hello N25, I just wanted to let you know that I'm on the related Genesys team and I'm doing some research to get you a comprehensive answer to your questions here! I'll reply again shortly with more info.

1 Like

Hey N25, I've looked into your questions. There's multiple things going on here:

Firstly, I looked up the email from hints in your posting - it sounds like you think there's only three words in the body ("e ew wer") but after that there is a big legal disclaimer that begins like this: "DISCLAIMER:\r\n This e-mail, including any attachments to it, may contain \r\nconfidential \r\nand/or personal information.[...]" So the real result is that there are indeed 109 tokens if you split on a single space. So for this part of your question I think you've got it right only you're not expecting that big legal disclaimer to be there.

Then, yes you're supposed to be able to Split using a newline as a delimiter by just specifying the expression like Split(Email.Message.body, "\n") but I looked in to this and indeed it was broken! So sorry! I have submitted a ticket, and in fact it's already completed and tested. I have started the process of deploying this fix to production and it should be available shortly. So sorry for this inconvenience.

Lastly, unfortunately I don't think you can Split with multiple delimiters. The text manipulation primitives are pretty basic. You should be able to process the body by words using the brute-force method of making a "position" integer and looping through the string yourself and comparing to the list of items you want to split on (like space, newline, table, non-char, etc) but you probably can't do it in a single built-in function nor effectively get the words into a pretty string-list.

I think that addresses all of your issues. Feel free to follow up if there's still something that I didn't cover.

Regards,
Dan

1 Like

Yeah, I didn't realize the disclaimer being added at the end sorry it was my bad. Good thing though that a fix was rolled out because of my query, glad to have indirectly contributed! I was hoping though for a simpler solution for a mixed space/return delimiter but I think we could work out something with what we have currently.

Thanks a lot for the information Dan! You really are a Grand Master! :slight_smile:

Hi @anon28798727, I just tried testing for \n Split delimiters however it seems to be still not working. Just wanted to verify with you if the fix for it has been rolled out before I test again, thanks!

Yes, it's in production. I tested it out to triple-check just now and it worked as I expected.

Ok, looks like it is working as it was separating the words in between newline (using Split(Email.Message.body, "\n")), however after singling out a value of the split collection using update data as shown below:

image

Then plugging Flow.TestWord into the Data Table Lookup action it somehow seems to not recognize it as a valid comparison even though the string in Flow.TestWord is one of the words in the defined data table. The same process has been done for " " split delimiters but for those it was working.

Could I be missing on something with regards to \n split delimiters?

Ooof! My bad, got victimized by Literal again! It's now working after correcting it as expression, thanks again!

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.