Forum Replies Created
-
Posts
-
So is it necessary to use “IF NO” condition branch to revert actions (like prepare email) that was once triggered before saving the form?
In my above setup the rule was matched to true once and it went to the “IF YES” branch and performed the action – prepare email. But the user quickly reverted the field value back (boolean) which caused the rule to matched = false. I do not have “IF NO” branch setup for this rule. My question is do we need to specify explicitly in the “IF NO” branch of this rule condition to revert the action which was once triggered (in this example prepare email)?
Hi Alex,
I installed v1.2.9 and now the search bar is disappearing from a list view as well. It is a good thing that its hidden when you view/add/delete a record (so that users wont get confused why the search doesnt work). However, when it gets disappeared from the list view itself, users are not able to search that list. Please have the search bar displaying in list views.Alex, I had sent the attachment via email since the forum couldnt upload it. Can you please confirm if you got it?
Alex,
I have attached the information you requested.This time I am noticing the rule is not getting triggered when its empty, its getting triggered when it has some data to begin with. I apologize for the confusion. The attached image should show the rule status on both conditions. I hope this helps.
Attached is the information you requested for.
Attachments:
Alex,
Can you please attach the script to check and fix dffs configuration for duplicate email id in this topic? The link in changelog is not linked. The email attachment i got was obscured by our email security service.
Thank you!I tested by adding and updating items that are configured with schedule email. Adding new item seems to create new item in ModernDFFSEmail list fine. Updating updates the ModernDFFSEmail record accordingly if it already exists. If it does not exist for some reason, it will create a new one. Everything seems to be working as expected.
The only outlier is orphaned ModernDFFSEmail list records. For this I added couple steps to the Flow for both send now and send later. You can add it to the users manual if it makes sense.
– Before sending the email, Get Item from the originating list using the listid and listitemid
– Add a condition to check If status code is success and data is not empty
– If true send the email
– If false do nothing
– Outside the condition block, add the delete action. This way the ModernDFFSEmail record will get deleted after sending the email or if the item in the originating list does not exist.Thank you for working on a fix this quick.
Thank you for this quick and simple workaround. I have tested this and can confirm this is working. I am not sure if the code is the same for send later flow. I had to use this to make it work.
replace(items('Apply_to_each')?['Body'],decodeUriComponent('%0A'), '<br>')Alex, I think i have nailed down the source problem. This happens with any list used as a source. If the field that is selected to show value when you setup your lookup field is not “Title”, this error shows up. I tried selecting a field that is not “Title” for some other lists and found out that “Get information from” and “In this column” are blank in field properties in DFFS.
I tried selecting “Title” field for the list i had issue with initially and this time it worked. I hope I am making sense and you can hopefully recreate this at your end.
Alex, my apologies. The screenshot was of an edit form. However, this behavior happens in ALL forms. Fields are just regular lookup fields. I added another lookup field (Lookup2) from a different list and that doesnt seem to have an issue. From what it looks like I am only getting this error when i create lookup fields from a particular source list. Because of this error, I am not able to select any value in edit and new form with DFFS enabled.
What puzzles me is that this error does not show up in out of the box sharepoint form. And I am able to select values for this lookup field.
I have attached a gif and screenshot displaying this behavior. Let me know if you need additional data.
Attachments:
