Workflow Hash and/or Commit message

Feature Request
#1

I’d like to share two stories and what I think might resolve them.
We have a few Losant applications that share the same code base, both on Workflows/Experiences etc.
We have them split for security/seperation at the moment, but are looking long term into a multi-tenant approach.

As we develop new features and pages, we come up to a release window where we manually move the newly developed/modified Workflows and experience resources from Development into the Production applications.

Sometimes for these nested workflows, you are only 75% certain something change, maybe in some four level deep loop on a function node. You’re not sure, so you copy it anyway, and then have to go fix all the GUID references to Data Tables, and callouts to other Workflows.

It would be nice if there was a hash visible of the workflow file itself, not dependent on the Application it is loaded into, but that I could compare and know that if I see hash: adx776542 , and I know I have a workflow with hash: ffg453444, then I know for sure there is a difference that I need to swap out the whole thing.

If I had two workflows with the same hash, then I would know that internally they are the same.
Right now you can only kind of surmise that based on the Last Modified Date, but even then they wont be exactly the same, as it gets updated when imported into an application.

Secondly, when a Workflow is saved, the option could be set at the Application level, to prompt for a Commit message. That way a developer could enter his/her notes about what was changed.
This may be annoying for rapid development, so potentially turned off at some level.

#3

Hey @Kyle_Stokes2,

This is a great idea. Working on creating a better development environment for Losant Developers is certainly on our roadmap, and this idea will be a great addition to that discussion.

I’m going to create a Feature Request for this and follow up with you as I learn more about it and its development.

Thank you,
Heath

#5

@Kyle_Stokes2 here’s something that won’t solve all of the issues you describe but may fix many of them …

Users with similar setups as you describe - nearly identical staging and production applications with changes from the former being migrated to the latter - have adopted an “ID mapping” within their application globals, and they reference those values within their workflows. This can greatly reduce the amount of manual changes needed when going between the two applications.

For example, let’s say you have a table called “Alert MetaData” within each application. First, in your staging application, you create an application global with the key idMap. Its value is a JSON object of the form …

{
  "alertMetaDataTable": "aaaabbbbccccddddeeeeffff"
}

…where “aaaabbbbccccddddeeeeffff” is the ID of the “Alert MetaData” table in the staging application. You can add additional resource IDs to this object as well.

In the production application, you set up the same global key (idMap), also with a JSON value. It has the same key of “alertMetaDataTable”, but the value is the ID of that table within the production application …

{
  "alertMetaDataTable": "111122223333444455556666"
}

In your workflow, say you have a Table: Get Rows Node that is pulling rows from the “Alert MetaData” table. Instead of directly selecting the table, you can instead set the table ID to {{globals.idMap.alertMetaDataTable}}, and with the mapping in place, there is no need to update the node when migrating this workflow from one application to the other.

This does come with a couple downsides:

  • In some nodes, the UI can be more helpful when we know the explicit resource being referenced; for example, in the Table: Get Rows Node, we can provide a typeahead list of columns we know to be in the table. We lose that ability once you reference a table by a variable - but all the functionality is still there.
  • This technique does not work for workflow triggers, since those do not support templates. Any trigger referencing an explicit resource will still need its ID changed on migration.

Hope this helps. Please reach out if you have any questions about this technique.

1 Like