All devices and workflows belong to a single application. Users can have multiple applications as needed. Dashboards do not belong to an application since a single dashboard can contain graphs and blocks for several different applications.

Creating Applications

There are a few places within the platform from which an application can be created; or, applications can be created at any time using the main Applications menu.

Create Application

When creating an application, you will be asked for three pieces of information:

  • Application Name: You are required to name your new application. The name can be changed at any time.
  • Description: Optionally, you may also provide a more detailed description of the application.
  • Owner: The application must be scoped to your personal Sandbox or to an organization for which you have the Editor role. The owner can be changed at a later date only if you have Administrator permissions for the parent organization (or Sandbox).

Create Application Form

Deleting Applications

Applications can be deleted on the settings page. Deleting an application cannot be undone. All devices, device data, workflows, and device recipes owned by this application will be permanently removed.

Delete Application

Application Log

The Application Log is a real-time log that displays helpful information about various aspects of your Losant application. It’s most useful for debugging purposes.

Application Log

As a real-time tool, the Application Log will always begin in an empty state. Logs will appear as actions on your application take place. Logs will show for the following cases:



  • Device State - When devices report state, a log will appear.
  • Device Commands - When Losant sends a device command, a log will appear.
  • Device Connection Status - When devices successfully connect or disconnect from Losant via the MQTT broker or the REST API, a log will appear.




  • Integration Messages - When Losant receives a message from an Integration, a log will appear.

Resources can be looked up and accessed from any page within an application by searching for it using the search bar within the subnavigation. The search panel can be opened by clicking on the search box or by hitting Option (⌥) + L on Mac or Alt + L on Windows.

Application Search Box

The search panel displays a list of recently accessed workflows and devices and links to common routes when it is first opened.

As a term is input, the options will filter and return resources that match. Resources can be looked up by name or partial name and results are restricted to the current application.

Application Search Panel Open

Application Globals

Application Globals

Application globals are a set of key/value pairs that are accessible inside of any workflow in the current application. This is a great place to store application-wide configuration that is used across multiple workflows, like phone numbers or API keys.

Any values configured here are accessible under the globals object on the payload in a workflow run. The globals will always be accessible on the application workflows; however, each global will only be exposed to edge workflows if Do not send to edge workflows is left unchecked.

Application globals can be overridden within a workflow by defining a different value at the same key in the globals for that specific workflow. You can read more about workflow globals here.

Application Archive

Application Archive

Application archive is a way to save a copy of an application’s device data on either Amazon S3 or Google Cloud Storage. The archive configuration allows you to specify which devices’ data should be backed up. After the data becomes older than 30 days, the application will create a directory for the archived date and a CSV for each device within that directory. After your archive configuration has been set you will also have the option to backfill your archive. This will dump all the data we have for the archival devices into your archive location. There is also a Test Archive button which will immediately enqueue a job to archive data from 31 days ago.

The reason we wait for the data to be older than 30 days is because device state data can be overwritten until the data is older than 30 days.


In order to configure archiving for AWS, Bucket, Region, Access Key ID and Secret Access Key are required. In order to configure archiving from Google Cloud Storage, Bucket, Project ID, and Account Key (JSON) are required. Both have one optional field, Directory Inside the Bucket, which specifies a directory for archival files to go; if left unset, the files will be appended to the top-level directory.


Before setting up your configuration to archive, make sure that your 3rd party user has the correct permissions. For Google Cloud Services, create a service account with ObjectAdmin permissions, which are the minimal permissions. For Amazon S3 archival, set the user’s IAM Policy to the following guidelines, such that bucketname is replaced with the actual bucket name:

  "Version": "YYYY-MM-DD",
  "Statement": [
      "Effect": "Allow",
      "Action": ["s3:getBucketAcl"],
      "Resource": ["arn:aws:s3:::bucketname"]
      "Effect": "Allow",
      "Action": ["s3:PutObject"],
      "Resource": ["arn:aws:s3:::bucketname/*"]

Generated CSV

Each generated CSV file will be placed within a directory named by the human-readable timestamp of the archived date. The files themselves will be named by the applicationId, deviceId, and the start and end time of the data contained in the file. An example directory and file would be:


Each CSV will have an ID column (for the device ID), a timestamp column (where the timestamp will be represented as a Unix timestamp in milliseconds), an ISO Date column (where the time is represented in human-readable form), as well as a column for each attribute on your device. The following is an example of a CSV:

"ID","Timestamp","ISO Date","Current","On","Inuse"