MongoDB Node

The MongoDB Node allows a workflow to query or update values in a MongoDB database and optionally store the result on the workflow payload.

MongoDB Node

Node Properties

The configuration of the MongoDB Node can be broken down into four major sections - configuring the connection, choosing the operation, setting up the arguments, and choosing what to do with the result.


MongoDB Node Connection Configuration

When configuring the connection, you must provide a Mongo Connection String URI, which must include a database name. You also choose here what collection that the node will be operating on. Both of these fields accept string templates, and so can be configured with values from the current workflow payload. In the example above, the MongoDB Node has been configured to connect to the embree database at with the username user and the password pass, and the node will be using the collection alertMapping.


Next you will need to choose the operation that will be performed against the database. Currently the node has support for the following operations:

The deprecated methods above will utilize other methods appropriate for your configuration.


MongoDB Node Arguments

Depending on the chosen operation, the expected arguments here will change. For example, with the findOne operation, there are two arguments - the query itself, and any options for the query. In the above example, we are not passing any options, but we are passing a JSON template - searching for a document in the collection with a deviceId field that matches the trigger ID that kicked off the run of the workflow. Most of the arguments for the various operations are expected to evaluate to JSON objects, and the node supports EJSON syntax for specifying things like ObjectIDs.

Both the query argument and the options argument allows users to choose the method by which the value will be set: a payload path, a string template or a JSON template.


MongoDB Node Result

Finally, you can optionally choose to store the result of the Mongo operation on the payload. For operations like insert or remove, you might not care about the result, but for an operation like the findOne above, you almost certainly do! In this case the result of the operation is being placed at the payload path working.queryResult.

Error Configuration

MongoDB Node Error Config

In the case that the provided JSON string fails to parse, there are two possible options for how to handle the error.

  • Error the workflow: Halt the workflow at this node, preventing further execution.
  • Store MongoDB at payload path: Configure a payload path at which to store the error.

Note: For edge workflows, this option is only available on edge version 1.15.0 or higher. On older versions, the workflow will always halt on errors.

Node Example

Here is an example payload after the above MongoDB Node has been run:

  "working": {
    "mongoResult": {
      "_id": { "$oid": "576ae72d4c0c31470b856483" },
      "deviceId": { "$oid": "56c8967bb8df0f0100d629120" },
      "phoneNumber": "212 867-5309",
  "data": {
    "current": 10,
    "on": true,
  "applicationId": "568beedeb436ab01007be53d",
  "applicationName": "Embree",
  "triggerId": "56c8967bb8df0f0100d629120",
  "triggerType": "deviceId",
  "deviceTags": {
    "floor": ["2"],
    "location": ["warehouse1"]
  "deviceName": "My Factory Device",
  "flowId": "56c74add04d0b50100043381",
  "flowName": "Power Usage Alert",
  "globals": { },
  "time": Fri Feb 19 2016 17:26:00 GMT-0500 (EST),

Node Errors

In the case that the provided MongoDB Query fails, there are two possible options. You can either error the workflow, or you can store the error at a path on the payload.

Below is an example of an error stored on the payload:

  "working": {
    "mongoError": {
      "message": "E11000 duplicate key error collection: test.alertMapping index: test1_1 dup key: { primary: \"Warehouse3\" }",
      "type": "MongoError"

Was this page helpful?

Still looking for help? You can also search the Losant Forums or submit your question there.