Playbook deactivate actions
Linus Laeubli
Member
I have noticed, that it's so far not possible to deactivate actions in a playbook.
In our secondary orchestrator I like to use that feature while developing, so kick out broken actions, and test them later on when I have time :)
3
Comments
Hey @Linus Laeubli , if I'm getting your question right, you could deactivate an action by following those steps:
Go to IDE under the Siemplify portal
from there choose your desired action under the integrations menu, toggle the activation bar and click save:
P.s - one of the things that i like to do while checking playbooks is to toggle actions into manual status while debugging workflows,
so the action wont automatically play, it will wait for your activation approval on the case overview:
Hi @Ori we have basically the same request, if I understood @Linus Laeubli correctly.
For us, ths usecase is that we have a "production" and a "staging" environment that use the same playbooks and same integration endpoints.
A playbook being tuned in Staging, however, should usually not send out a notification ticket to our SOC, for example, thus we'd like to set this one step to "disabled" directly in the playbook. The underlying integration action, however, should still be enabled and available - if I'm not mistaken we would not even be able to save the playbook if it contained unavailable / disabled integration actions, right?
Hi @Marek Kreul , in case of multiple environments, there's the integrations manager to create different instances where you can have copied integrations and even configure / modify their actions code however you want.
Using this will let you manage different playbooks at different environments in different instances and maybe be a sorting solution for this kind of problem.
Also, while building a playbook, you can choose the instance of the action in which you want to operate in. You can modify or remove parts of the action code in a testing action instance for the testing phase and whenever you want to switch to production all you have to do is change the instance in the action within the playbook.
Refer to this article regarding Supporting Multiple Instances
-Ori.
Hi @Ori unfortunately none of that is really practical.
Creating different instances of e.g. Splunk Integration would mean that we have 1 instance with a "readonly" account, and another with a read-write account.
This applies for all integrations where we run into such a problem, and will thus double the efforts to get the necessary accounts in the destination systems in the first place, make it harder to ensure they are appropriately authorized, and maintain their credentials and validity in the long run. But it's true, this would be a functional workaround for the problem.
The part with "modify or remove parts of the action code" wouldn't work, because this would mean creating a custom action and using this custom action in the playbook. Whenever we want to sync the playbook between PROD and STATING, we'd then have to exchange one for the other.
Ultimately, what we want to use is an automated way of syncing playbooks between multiple platforms, making sure that a change applied in the Staging System can be applied to PROD without the burden of having to put the changes in manually, or running the risk of introducing errors during manual sync. And these automated syncs would be frequent, thus it's not an option to exchange playbook actions each time.