I've created a script to create new LogicApps using PowerShell and deploy them to my Azure ResourceGroup. It uses a schedule recurrence and calls an action on these specific triggers.
The script works and gets the job done (I get to create and update my LogicApp). My issue however is that the LogicApp is triggered every time I do an update in addition of using the recurrence trigger.
Among things I've tried, I've attempted to disable, update then re-enable, but sadly it just triggers as soon as it is enabled back.
The reason around this is I want to run the action on specific time only, and it doesn't match the moment I'm deploying it.
Is there a way to prevent the Logic App from triggering?
If it helps, I am using the New-AzResourceGroupDeployment cmdlet. I've browsed the documentation but there doesn't seem to be any mention as to whether I want to run it immediately or not.
If you set the Start time parameter, that should resolve your issue:
Related
I'm trying to implement automatic backfills in Argo workflows, and one of the last pieces of the puzzle I'm missing is how to access the lastScheduledTime field from my workflow template.
I see that it's part of the template, and I see it getting updated each time a workflow is scheduled, but I can't find a way to access it from my template to calculate how many executions I might have missed since the last time the scheduler was online.
Is this possible? Or maybe, is this the best way to implement this functionality on Argo?
I created a scheduled trigger which executes an ADF pipeline in our development environment.
The trigger runs at 4AM on a daily basis.
I now want to release this process into our test ADF environment but the trigger should kick of at 6AM on a daily basis.
I cant find a method of dynamically changing these values based on environment.
Has anyone come across a solution for this?
Changing trigger settings can be achieved by using ADF utils and custom parameters definitions file, I included an example in this post: https://www.mutazag.com/blog/code/tutorial/ADF-custom-paramaters/#changing-trigger-settings
I've recently built a pipeline in ADF. I placed a trigger that launches it every day at a specific time.
But if my computer goes off, the pipeline doesn't trigger. Is it necessary to keep the computer on, knowing that everything happens in the cloud? If that is the case, can you advise the alternative?
Is it necessary to keep the computer on
No this is unnecessary. Once you published the whole data factory, there should be no relationship with your own machine.
Refresh your page, and then see whether the trigger is still in the data factory.
If still not work, please contact technical support of microsoft.
Not a duplicate of this
I have a pretty simple CRM workflow, which basicly just adds some values to some fields that doesn't get filled whenever a user creates a new object. My challenge here is that a lot of objects are already created in CRM, with a lot of null values. We are talking thousands. So instead of asking the client to open every single object and running the workflow, I was thinking I could create a second workflow which initiates the first workflow to run on all current objects. Is this possible and how should I do it?
The problem is not the workflow execution. Its the selection of the record. Dynamics CRM doesn't have the possibility to execute a workflow against a massive amount of records.
You have to script a little program which selects the records for which you would like to run the workflow and start the workflow for each of them.
See How to run ondemand workflow over all pages
So in one part of our customised Salesforce system, the following happens:
a trigger changes the value of a picklist on a custom object
a Workflow rule detects that change and fires off an email.
Since about the 4th of December though, it seems to have stopped working.
edit: The Debug Logs show that the trigger is firing and changing the value of the picklist, but no Worflow Rules are evaluated.
The workflow rule is pretty simple, so I don't really understand whats preventing it. The details of the rule are:
Operates on a custom object.
Evaluation Criteria: When a record is created, or when a record is edited and did not previously meet the rule criteria
Rule Criteria: ISPICKVAL(Status__c, 'Not Started')
Active: Yes
Immediate Workflow Actions: an email alert
Edit: The Rule does fire if I manually update the object to set the appropriate status. But it isn't firing when a trigger changes the status.
Edit: Did something change on Salesforce around December 4th 2009? That seems to be when this stopped working ...
Any ideas?
If you had said "the trigger does not fire the workflow, even though a manual change via the UI does", I would have responded something like...
Absolutely. That's how it is designed.
Salesforce do not allow anything
automated to invoke anything automated
(ie you cannot start a WF from a trigger or another WF).
Given that you say this stopped working earlier in the month, I am frankly astonished! We wanted to achieve something like this, would have been about 10 months ago, and Salesforce told us it could not be done; they like to keep tight control over processes that could potentially run away and consume large CPU (because of the multi-tenanted nature of the offering), hence the stringent governor limits...
This may have changed recently, of course, we built work-rounds to get round the restriction...
To answer my own question ... I eventually found out what this was.
The Salesforce Spring '09 Workflow Rule and Roll-Up Summary Field Evaluations update was rolled out to all orgs at the start of Dec '09, and changed certain Workflow behaviours.
The update improves the accuracy of
your data and prevents the
reevaluation of workflow rules in the
event of a recursion.
Our particular problem was that we needed Workflow to be evaluated twice on a single object after the initial action - we had a series of changes to a status field that needed to kick off different things. After the Spring '09 update, Workflow is only evaulated once for an action on an object.
So, it did work, but then the platform changed, and it didn't work anymore. Time to write some code.