Connect with a PowerFlow Product Manager
We Want Your Insights! We would love to connect with you one-on-one to gather your feedback and insights about PowerFlow. Your experiences are key to shaping the future of our product! Why Chat? Share your thoughts on how we can improve Discuss any challenges you’ve faced Help us prioritize features that matter to you Please note that these calls are not intended to address issues that can be resolved through Support Cases. Ready to make an impact? Book a call with us now! Thanks for being part of our journey!Convert Customization to PowerFlow Jinja Template
Sometimes when syncing devices from SL1 into ServiceNow as a Configuration Items there can be a mismatch. ServiceNow may list the name as Fully Qualified Domain Name and SL1 will use short name. This setting can be updated in SL1, but in some cases the SL1 team would rather see short name than FQDN. This can be setup on a per SL1 Device Class basis. PowerFlow Using the following Jinja2 “if statement” the device name in SL1 can be converted to use “Device Hostname,” in SL1 instead for Microsoft SQL Server Databases. This excerpt of code would go under attribute mappings for name on the ScienceLogic side mapping to name on the ServiceNow side: {%- set output = [] -%} {%- if (device.device_class|trim) in ['Microsoft | SQL Server Database'] } {%- set output = device.hostname -%} {%- else -%} {%- set output = device.name -%} {%- endif -%} {{ output }} Example:PowerFlow v3.1.1 & PFCTL 2.7.11 Release
Hello, We are pleased to announce the release of PowerFlow v3.1.1 and PFCTL v2.7.11, which contain important fixes to the PowerFlow 3.1.0 and PFCTL v2.7.10 releases. Please read the Release Notes carefully before installing these releases. These are the highlights only. FEATURES This section covers the features that are included in SL1 PowerFlow Platform version 3.1.1: The following images are included in this release of PowerFlow: registry.scilo.tools/sciencelogic/pf-api:rhel3.1.1 registry.scilo.tools/sciencelogic/pf-couchbase:6.6.0-13 registry.scilo.tools/sciencelogic/pf-dex:2.37.1-10 registry.scilo.tools/sciencelogic/pf-worker:rhel3.1.1 registry.scilo.tools/sciencelogic/pf-gui:3.1.1 registry.scilo.tools/sciencelogic/pf-pypi:6.3.1-14 registry.scilo.tools/sciencelogic/pf-rabbit:3.8.35-6 registry.scilo.tools/sciencelogic/pf-redis:6.2.14-5 ISSUES ADDRESSED The following issues were addressed in this release: Addressed an issue that prevented new schedules from functioning correctly if an application used an ID with both upper and lowercase letters. (Case: 00495740) Jinja2 is now available in the PowerFlow Devpi Server, which allows the ServiceNow CMDB SyncPack to use it while rendering templates. (Case: 00492419) Thank you, Release ManagementServiceNow Base SyncPack v3.8.2
Hello, We are pleased to announce the release of the ServiceNow Base version 3.8.2 SyncPack. The following feature was addressed in this release: Added updates to support "ServiceNow CMDB" SyncPack version 3.6.2. This release is made to work with SL1 version 12.1 or later SL1 PowerFlow version 2.6.0 or later Base Steps SyncPack version 1.5.5 or later ServiceNow version Tokyo or later, with Web Services enabled With the release of this SyncPack, older versions of the ServiceNow Base SyncPack have been suspended. Thank you, Release ManagementServiceNow CMDB v3.6.2 SyncPack
Hello, We are pleased to announce the release of the ServiceNow CMDB v3.6.2 SyncPack. The following enhancements and issues were addressed in this release: Addressed an issue that caused incorrect relationships to be sent to ServiceNow when only child devices were sent for updates. (Case: 00492036) Addressed an issue with the "Sync Devices with SQL" application that caused the device collection mode/state to always show as "active" when synced to ServiceNow, regardless of the actual device state. (Case: 00489043) Addressed an issue where CI classes in ServiceNow with a 'region' field caused issues with disconnects being sent from PowerFlow. The 'region' field from ServiceNow on a CI is now saved on the Python object as "snow_ci_region". (Case: 00493761) Updated the SyncPack to correctly handle an SL1 platform change starting in version 12.1.0 for creating custom links through GraphQL. This release is made to work with SL1 version 12.1 or later SL1 PowerFlow version 2.6.0 or later Base Steps SyncPack version 1.5.5 or later ServiceNow Base SyncPack version 3.8.2 or later ServiceNow version Tokyo or later, with Web Services enabled ScienceLogic SL1: CMDB & Incident Automation certified application version 1.0.81 With the release of this SyncPack, older versions of the ServiceNow CMDB SyncPack have been suspended. Thank you, Release ManagementScienceLogic - ServiceNow Integrations: ITOM Licensing Requirements
ScienceLogic maximizes customers' investments in ServiceNow through its powerful suite of pre-built integrations, referred to as SyncPacks. ScienceLogic offers certified ServiceNow scoped applications for streamlined platform integration, accessible via the ServiceNow Store, ensuring seamless compatibility. Understanding the licensing requirements for ServiceNow integrations is crucial for informed decision-making. This document seeks to clarify the IT Operations Management (ITOM) licensing requirements for ScienceLogic integrations with ServiceNow. Its purpose is to eliminate any confusion regarding which integrations necessitate ITOM licensing. Note: ServiceNow’s ITOM licensing is further organized into different tiers. This document is not intended to help identify the suitable tier for your requirements. For any questions related to this, please contact ServiceNow. Scoped Application ServiceNow Module ITOM License requirement ScienceLogic SL1: Customer Service Management Integration Customer Service Management - Cases No ScienceLogic SL1: Incident Automation IT Service Management - Incident No ScienceLogic ServiceNow Integration IT Service Management - CMDB * Situational ScienceLogic SL1: Service Catalog Automation IT Service Management - Service Catalog ** Situational Service Graph Connector for ScienceLogic IT Operations Management - CMDB Yes ScienceLogic Event Integration IT Operations Management - Events Yes * ScienceLogic is actively adding support for cloud infrastructure mappings within our integrations. To effectively leverage these features in accordance with ServiceNow best practices, you might require ITOM licensing. Customers can contact their ScienceLogic representatives for cloud mapping questions. ** ITOM licenses are necessary only if you are implementing a CMDB using ITOM FAQs Here are some frequently asked questions (FAQs) from our customers Q: Are there other scenarios where one would need IT Operations Management (ITOM) licenses for CMDB? A: The necessity for ITOM licenses is primarily influenced by the specific goals of your organization. Customers of ScienceLogic are not required to adopt ITOM unless their integration module is inherently ITOM-based. We observe that customers generally opt for ITOM in the following situations: To deploy out-of-the-box ServiceNow automation for ensuring data quality and reliability. When transitioning to a more advanced, ServiceNow-defined CSDM (Common Service Data Model) framework. Q: Do Business Services in ScienceLogic need IT Operations Management (ITOM) licenses to be integrated into ServiceNow? A: No, it does not. ScienceLogic integrations leverage out-of-the-box ServiceNow CMDB tables, eliminating the need for ITOM licenses. You can effectively replicate ScienceLogic Business Service Models in ServiceNow by leveraging our integrations. Customer Testimonials Discover what our customers are saying about our integrations. “ We like that ScienceLogic has a tight integration with ServiceNow and particularly the fact that we don't need to deploy the additional discovery modules from an integration perspective. ” “ We are able to have a single pane of glass using ServiceNow. All monitoring events and CMDB population is managed by ServiceNow. ScienceLogic is a great monitoring system that integrates well with ServiceNow using its integration server, which provides workflow and rules that work with our systems. ”
Powerflow Application Queue Trigger Failure
Hi All, I've Developed a Runbook Action within ScienceLogic, that triggers a Powerflow Application if certain Runbook Automation Policy conditions are met. Upon execution, it sends the following payload: "params": { "configuration": configuration, "event_policy_name": EM7_VALUES['%_event_policy_name'], "event_details": EM7_VALUES, "organization_name": EM7_VALUES['%O'], "system_url": system_url, "queue": queue } These parameters are specified as inputs, and some are derived from the EM7Values. When the Runbook Automation linked to this Action executes against a specific Event Policy raised on a Device, i can see a success message in the "Event Notifications" window, and i can see all inputs and variables are passed through in its entirety. The real issue comes when you open Powerflow. The Application immediately fails, and an error message stating that theres an "Internal Request Error: pop from empty list". This error doesnt make any logical sense as the parameters i pass through are either JSON or String Payloads, no Arrays. I've been doing testing with the payloads, ensuring that the configuration being referenced exists, and confirmed all these are in place and are working fine. I then removed the "queue" value from the params body, and only passed the rest of the parameters, this succeeds and the application executes without incident. What's interesting, even if manually executing the application in the UI with a custom parameter set, as soon as you specify the queue, it fails. Now its important to know that we've only recently created the queues on a development system, and this is the first time we're testing with the newly created queues. I was hoping that someone in this community might be able to shed some light as to why this might be happening? Could it be that the queues are unreachable, and therefor when not specifying the custom queue, it defaults to the celery queue, which are reachable, and therefor works? If the queues are the problem, what could be done to try and fix the problem? Any and all contributions are welcome. Sincerely AndrePowerflow Application Immediate Failure
Hi All, I've Developed a Runbook Action within ScienceLogic, that triggers a Powerflow Application if certain Runbook Automation Policy conditions are met. Upon execution, it sends the following payload: "params": { "configuration": configuration, "event_policy_name": EM7_VALUES['%_event_policy_name'], "event_details": EM7_VALUES, "organization_name": EM7_VALUES['%O'], "system_url": system_url, "queue": queue } These parameters are specified as inputs, and some are derived from the EM7Values. When the Runbook Automation linked to this Action executes against a specific Event Policy raised on a Device, i can see a success message in the "Event Notifications" window, and i can see all inputs and variables are passed through in its entirety. The real issue comes when you open Powerflow. The Application immediately fails, giving no error and no explanation as to why it fails. I've been doing testing with the payloads, ensuring that the configuration being referenced exists, and confirmed all these are in place and are working fine. I then removed the "queue" value from the params body, and only passed the rest of the parameters, this succeeds and the application executes without incident. What's interesting, even if manually executing the application in the UI with a custom parameter set, as soon as you specify the queue, it fails. Now its important to know that we've only recently created the queues on a development system, and this is the first time we're testing with the newly created queues. I was hoping that someone in this community might be able to shed some light as to why this might be happening? Could it be that the queues are unreachable, and therefor when not specifying the custom queue, it defaults to the celery or 'priority.high' queue, which are reachable, and therefor works? If the queues are the problem, what could be done to try and fix the problem? Any and all contributions are welcome. Sincerely AndrePowerflow Application Immediate Failure
Hi All, I've Developed a Runbook Action within ScienceLogic, that triggers a Powerflow Application if certain Runbook Automation Policy conditions are met. Upon execution, it sends the following payload: "params": { "configuration": configuration, "event_policy_name": EM7_VALUES['%_event_policy_name'], "event_details": EM7_VALUES, "organization_name": EM7_VALUES['%O'], "system_url": system_url, "queue": queue } These parameters are specified as inputs, and some are derived from the EM7Values. When the Runbook Automation linked to this Action executes against a specific Event Policy raised on a Device, i can see a success message in the "Event Notifications" window, and i can see all inputs and variables are passed through in its entirety. The real issue comes when you open Powerflow. The Application immediately fails, giving no error and no explanation as to why it fails. I've been doing testing with the payloads, ensuring that the configuration being referenced exists, and confirmed all these are in place and are working fine. I then removed the "queue" value from the params body, and only passed the rest of the parameters, this succeeds and the application executes without incident. What's interesting, even if manually executing the application in the UI with a custom parameter set, as soon as you specify the queue, it fails. Now its important to know that we've only recently created the queues on a development system, and this is the first time we're testing with the newly created queues. I was hoping that someone in this community might be able to shed some light as to why this might be happening? Could it be that the queues are unreachable, and therefor when not specifying the custom queue, it defaults to the celery or 'priority.high' queue, which are reachable, and therefor works? If the queues are the problem, what could be done to try and fix the problem? Any and all contributions are welcome. Sincerely AndreMicrosoft Teams SyncPack v2.0.0 and Microsoft Teams Automation PowerPack v200
Hello, We are pleased to announce the GA release of the Microsoft Teams v2.0.0 SyncPack and the Microsoft Teams v200 Automation PowerPack integrations for PowerFlow. These releases represent a complete re-architecture of the Teams integration and was driven by a change by Microsoft to the ways Teams works, as detailed in this blog post last fall. Essentially, Microsoft 365 Connectors have been retired, and Microsoft Power Automate was introduced as a replacement. Our new packs make use of Microsoft Power Automate. Please read the release notes and manual carefully, as we have included important details you will need to know before configuring your integration. Here are some highlights from the release notes: Updated the "Create Channel For Event" application to trigger event notification in Microsoft Teams based on the "ms_teams_webhook_url" configuration option, which is a webhook URL generated from Microsoft Teams. When acknowledging an event in Teams, the username of the user who acknowledged the event message is now displayed in SL1. When an event occurs and the event message is posted to Teams, you have three options for handling the event message: Add Note Acknowledge Resolve Added the "enable_existing_channel" configuration option to the "Create Channel For Event" application to allow event notifications to post to an existing Teams channel specified in the "channel_id" configuration option. Updated the "Delete Event From SL1" step name to "Resolve Event From SL1". The Microsoft Teams PowerPack will now create events and event notifications for both major and critical events. Removed the "Major Event Notification to MS Teams" application from the SyncPack. The PowerPack now handles both Critical and Major event notifications using the "Create Channel for Event" application. Removed the "Outage" and "Create Channel Event Notification" applications from the SyncPack. Previously, a refresh token was used to gather user information from adaptive card reactions. The refresh token was removed, and now the user ID is retrieved directly from the workflow using authentication through the Microsoft Authentication Library (MSAL). Optimized the "Microsoft Teams Power Automate" application by reducing API permissions to ensure minimal permission exposure while maintaining essential functionality. This enhancement improves security and aligns with best practices for access control. Microsoft is changing its API policy and the way to use it for adaptive cards. As a result, ScienceLogic has upgraded this SyncPack with the Microsoft authentication library, which is the new way to interact with Microsoft applications in a more authenticated process. For more information, see Microsoft's documentation on MSAL . NOTE: Group calling is not available currently with these packs. Thank you, Release Management
