This site is in read only mode. Please continue to browse, but replying, likes, and other actions are disabled for now.

⚠️ We've moved!

Hi there!

To reduce project dependency on 3rd party paid services the StackStorm TSC has decided to move the Q/A from this forum to Github Discussions. This will make user experience better integrated with the native Github flow, as well as the questions closer to the community where they can provide answers.

Use 🔗 Github Discussions to ask your questions.

CMDB integration


I’m new to SS, please be gentle.

I want to use a REST API on SS to read “new discovered device” alerts from an external “network discovery” device, so GET the alerts from an external device, store the alert ID’s (and the device ID) on SS and use SS to compute which alerts you have already processed then from SS GET the device properties for any new devices from the external device and store the results in SS. Maybe it makes sense for SS to be a mail destination for alerts from the network discovery device and do it that way?

UPDATE: I found the email pack, so I’m thinking of setting up an email account that SS can access via IMAP and having the network discovery device email new discovered device alerts to the email address. Now I’m a bit confused stackstorm-email/ at master · StackStorm-Exchange/stackstorm-email · GitHub in the “email.imap.message trigger | Example trigger payload” section shows “body”: “hello from stackstorm!\n” and “subject”: “test email with attachment” now does that mean the entire body (and subject) gets put into single values, if so, can I parse this and create multiple key value pairs from the email body, say I want to store just the alert_ID and device_ID numbers from the email body in two key value pairs, is this possible?

Then I would want to populate Device42 CMDB with the new devices but I’m more interested in figuring out the above network discovery part first.



This looks like a good use case for a polling sensor. We have a bunch of ticketing integrations where we poll the ticketing system for updates on a list of open tickets. We then send a trigger which a rule picks up - and kicks of another action or workflow.