Feature Requests

We are encountering challenges while testing new adaptor changes on the Lightning platform because the adapter must first be released on npm before it can be pulled into the Lightning environment. This creates a bottleneck in the development workflow, leading to delays and inefficiencies in testing and validation.

Right now if testing a workflow in the Inspector view, I can see a list of 5 Inputs I've recently used... but I have no idea what these inputs are (it's almost impossible to remember the uuid names), when they were created, and what they are for. Therefore, I'm often saving test cases I like in Github with human-friendly names (e.g., patientZeroWithReferral.json)... and then re-pasting this input again whenever I need it into the Input panel (bc I can never recall the UUID it's saved under). It would be great to be able to maintain a collection of Inputs that I expect to use regularly for testing, and be able to give them my own names/labels and maybe even tags. I'd also like a view where I can see ALL Inputs I have saved for a project so that I can edit/delete these over time. Also, as I create a new Input -> there is no JSON validation or formatting to help me check what I'm inputting until I click "Create New Work Order". This Input view also has no JSON formatting/Monaco editor view: https://app.openfn.org/projects/57862287-23e6-4650-8d79-e1dd88b24b1c/dataclips/f96ec031-7cf2-41e6-81b1-57553cb48e29/show And how cool if Inputs could also eventually be integrated with Github.

When designing workflows, it's common to create several seperate but connected workflows representing business processes, and for those workflows to call each other. Right now this is done by creating a HTTP step and calling out to an endpoint at openfn. A better solution would be to create a Step, set its Type to "Trigger Workflow" (or something), and then select the workflow name from a picklist. The Step would have a special icon to look less like a regular step. The Step could have interactions, like double-clicking to open the Workflow in a new window. Or maybe even expanding the other workflow INSIDE the primary one, so you can see all the steps in one place, but the two workflows are still visually distinct

In the history page that lists work orders, I would like to see how that workflow was triggered(cron or web hook) or if it was manually triggered by a users. Sometimes I would be browsing through the history looking for the run I triggered but I wouldn't be able to tell if there are multiple work orders for that workflow(triggered by different users at a similar time)

Right now super users have to (1) create users, and then (2) go into the DB via the backend to manually change the role of these users from "admin" to "super".

As a OpenFn workflow engineer, I would like to see when my project was last synced to Github from and last synced from Github in the Sync to Github page. Currently I'm only able to see that the repo is properly configured and the branch its configured to, but i would like to see when it was last successfully synced to/from Github.

As a project admin I would like to view who owns a credential in my project.

From a customer working with OpenFn locally: As a super admin, I want to deploy multiple openfn projects at the same time. Is it possible to specify an array of project.yaml files?

As a project admin, I want to be able to remove credentials that are shared with my project by other team members.

I would LOVE to see a browser-based version of the openfn runtime which allows users to execute job code in the browser. The basic idea is that you go to the doc site, look at an example of some adaptor code, and click "run". It'll run that code in your browser (probably with mock data) and show you the result. Then you can edit the code and run again to see how the output changes. I also envisage a standalone playground page, like jsbin or jsfiddle, where you pick an adaptor from a list, enter code freely, and can share the playground/sandbox through the URL so that other users can see it to. I built a similar thing in a past life (see https://cambridge-intelligence.com/data-visualization-playgrounds ) and it totally transformed the way we handled support. So easy to build an example in the playground, test it, and send it on to users. Its an incredibly powerful learning tool. There's a lot of work here by the way and more details on github. Some steps include: packaging the runtime and adaptors for the browser maybe baking mock data into adaptors (so they can execute "offline" and without credentials) creating the actual playground (& editor) interface Integrating with the doc site (so that all examples use (or link to) a playground UI)