The office365 trigger when new -email arrives (V3) is my logic Appp trigger condition.
The workflow does following:
Triggered on incomnig e-mails
check if sender is an AD User, if not send to a special Mailaddress
analyse the subject and put informations gother in new mailboydies and
distribute the mail to other mailboxes
I have seen a few cases I don' t understand, what it is the reason for that.
I got a trigger sicceeded but the trigger doe not fired Why?
image1: trigger History
image 2: not Fired Triggers
Screenshot shows succeeded triggers but not fired to start a run.
In this time spawn there was no email in the inbox.
I got a trigger failed ( i cannot reconstruct which mail could the reason).
image3: failed Trigger
for this case I can say nothing i found no e-mail at this time,
but it is possible that there was through Dectivation/Activation of logic app
old not readed mails ttries to trigger.
it was the first trigger after creation of this Logic app for testing
(copied from other subscription).
Can someone say me possible reasons for this 2 situations?
A status of skipped just indicates that the nothing new was found to fire the logic. Because the trigger will do check operation every once in a while even though the mailbox do not receive new email.
I think you do not need to worry about the records under "Trigger history". You just need to check the records under "Runs history". The records under "Runs history" can give a more intuitive picture of what's your logic app going on.
Related
Let's say we need to send user an email and wait for user to reply and then continue the workflow. Should we create an async activity to send the email, and when the reply email comes, we complete the activity? Or should we create a normal activity to send the email, and then the workflow await a signal, and when the reply email comes, we send the signal to the workflow? Are these 2 options equivalent? Or there are some difference can be used to decide which one to use for different activities?
Thanks in advance
I recommend the activity then signal approach for this use case. The reason is that sending an email and waiting for a reply are two different tasks with different timeouts and retry policies.
If send email activity fails it is expected to be retried on a short timeout on a pretty tight retry schedule. At the same time the timeout for the user action is expected to be much larger (potentially days or weeks) and is usually not retriable.
Edit to answer the retry question:
But what if we do want to retry? Say we expect the user to reply the
email within a day, otherwise we send it again. We can retry the
entire workflow but that is not ideal since send email and user reply
is only part of the workflow. Should we make it a child workflow and
have retry on the child workflow?
You retry the whole interaction. See the fileprocessing example of retrying part of a workflow. Here are Go SDK and Java SDK versions of it.
In our design we have something of a paradox. We have a database of projects. Each project has a status. We have a REST api to change a project from “Ready” status to “Cleanup” status. Two things must happen.
update the status in the database
send out an email to the approvers
Currently RESTful api does 1, and if that is successful, do 2.
But sometimes the email fails to send. But since (1) is already committed, it is not possible to rollback.
I don't want to send the email prior to commit, because I want to make sure the commit is successful before sending the email.
I thought about undoing step 1, but that is very hard. The status change involves adding new records to the history table, so I need to delete them. And if another person make other changes concurrently, the undo might get messed up.
So what can I do? If (2) fails, should I return “200 OK” to the client?
Seems like the best option is to return “500 Server Error” with error message that says “The project status was changed. However, sending the email to the approvers failed. Please take appropriate action.”
Perhaps I should not try to do 1 + 2 in a single operation? But that just puts the burden on the client, which is worse!
Just some random thoughts:
You can have a notification sent status flag along with a datetime of submission. When an email is successful then it flips, if not then it stays. When changes are submitted then your code iterates through ALL unsent notifications and tries to send. No idea what backend db you are suing but I believe many have the functionality to send emails as well. You could have a scheduled Job (SQL Server Agent for MSSQL) that runs hourly and tries to send if the datetime of the submission is lapsed a certain amount or starts setting off alarms if it fails as well.
If ti is that insanely important then maybe you could integrate a third party service such as sendgrid to run as a backup sending mech. That of course would be more $$ though...
Traditionally I've always separated functions like this into a backend worker process that handles this kind of administrative tasking stuff across many different applications. Some notifications get sent out every morning. Some get sent out every 15 minutes. Some are weekly summaries. If I run into a crash and burn then I light up the event log and we are (lucky/unlucky) enough to have server monitoring tools that alert us on specified application events.
I am using Microsoft Dynamic CRM Online and have a workflow issue. When the status of a case is modified, there is a workflow that kicks off to send members of the case team an e-mail. The problem is, it is sending the message to members of the team that have been recently disabled.
Example: User Jack Bauer is added to Case FOX24. One month later, Jack's account is marked as disabled. The following week, the status of the case is updated and a workflow is triggered to send team members an e-mail.
Is there a way inside a workflow to prevent the email from being sent if the user is disabled?
So far, I haven't found anyway to stop the email.
I solved my problem by creating a child workflow to remove any disabled users from the case specific attributes before the email is sent. The new process contains the nine checks for disabled users as well as an Update Record action for each check to {clear} the value of the associated attribute. It is marked as "Run on demand" so users can clean the Case record anytime they desire.
The child workflow will be called once per email in the parent workflow because they are sent using different timeout periods. Even if a user is disabled in the week or so between the first and second message, they shouldn't receive the messages.
Add a condition into the workflow which checks the status of the record in the 'To' field of the email.
I've build a simple task management webapp: User A fills up a form, hits submit button, sends data to a server and if the data validates User B gets assigned to this task.
I'd like to notify User B by email on this new assignment. However User A can alter the task data or even delete the task and the email that already has been sent would be incorrect in this case.
One approach is to delay the notification email for couple of minutes and then upon sending update the email message if needed.
Which are the best practices for notifications sending?
I think you have a few choices:
Send out emails whenever task status changes. Don't include details; send a link to user B to let them see what the changes are.
This is a good example of Why Starbucks Does Not Use Two Phase Commit. User B will tolerate "dirty reads" because they aren't life altering.
Send out all notification emails asynchronously on a fixed schedule. Have a timed task query a database, generate all the emails, and send them at once. The task will have the chance to only send the latest one. If user A assigns a task, makes updates, then deletes, user B will only get the last meaningful one. In this case, an assign followed by a delete might result in no email being sent. Only an assign or update as last state will result in an email being sent.
Background
Workflows and dialog processes in CRM 2011 (and CRM Online) allow us to send emails to email-enabled records (such as contacts, accounts and users). In the event that the email-enabled record does not have an email address, the process will fail with an exception (workflows remain in waiting state, dialogs throw the exception):
Unhandled Exception:
System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault,
Microsoft.Xrm.Sdk, Version=5.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35]]: Object address not found on party
or party is marked as non-emailable
My scenario
In many scenarios, faulting the entire process because an email couldn't be sent is heavy-handed (equally I accept that there are many scenarios where this behaviour is desireable too). As an example, if I am creating and updating many records as part of a large workflow and simply wish to send a simple, courtesy confirmation email at the end of the process, I do not want the entire process to fail simply because this final step could not complete. I can add a simple conditional statement to my workflow to check presence of address prior to the send-email step. This works but I (or more specifically, my users) need to remember to do this for every single email step that is created.
Theoretical solutions
Ideally, I would have a child workflow that would accept an email object as input and then I'd run a little check to confirm that there is a sender and recipient before sending the email. If data is missing I could either silently fail the sub-process or invoke different logic such as email the originating user or write an error record.
Howver, given the following....
Custom workflow assemblies are still not supported in CRM Online
Workflows do not accept incoming parameters
Even dialogs don't support an "email object" as an input parameter, or an array of values (e.g. for recipients) as an input parameter
Child dialogs do not return control to the caller after completion
...I am struggling to conceive of a pattern or solution that would effectively allow me to avoid the users having to remember to put a hard-coded check in every workflow or dialog that they create (to check for the presence of a recipient email address).
Ideally I want something like a generic child-workflow that takes the email object (or a serialisation or other representation of it), makes the checks and sends the email if it can.
Over to you
I've tried to design a custom solution but it quickly gets over-engineered (plugins on system entities etc). Otherwise I can't see a way of avoiding putting the onus on the users. Has anyone else encountered a similar requirement and better still, devised a solution?
Well I can think of a pretty straight forward solution.
New field on email - "Auto Send", bit, default No
New workflow - Create of Email, If "Auto Send" == Yes && Send contains data && Recipient contains data -> Send Email in context
In all your other workflows, instead of using the "Send Email" action, use the "Create Record" action to create an email record, populate the email as normal, but also populate the "Auto Send" field.
This way users can pretty much create an email as normal, but you get to use a single workflow to perform validation logic and actually send it.