Skip to main content

In NWC , it appears that all users with Designer rights have access to edit all workflows in the tenant and use all connections created by other users as well.  What are the plans to allow more granular permissions?  

In the future, will the following be possible:

  • A workflow designer should be able to specify which other users could edit or publish that workflow
  • The creator of a connection be able to specify which users may use that connection.

It would be useful if this works with NWC Groups and not individual users. Example:

User A is member of the group HR and could therefor edit all workflows/use all connections related to that group. A user could be member of multiple groups. An admin is member of all groups. Having admins per group seems useful for big companies.


Hi ‌ and ‌,

Thanks for the feedback/suggestions. We absolutely intend to add permissions to connections and workflows, and we realize we'll need more granularity in permissions. A few things we are considering:

1.) Role/group based permissions. IE, someone in HR by default gets access to only HR workflows and specific connections such as perhaps ADP or Workday.

2.) Specific permissions - when creating a connection or workflow, allowing the designer to designate who has access. This can get tricky, as we'd need an additional page to manage this since users will be added and removed quite often.

If you have any other specific requests/requirements about how you'd like these permissions to behave, please feel free to add those!

Thanks!


Thanks Renai - In addition to the items above, is there a plan for integrating External Start events with OAuth?  


Hi Tom,

Good question.  

The Xtensions framework (soon to be available in advance preview later this month) will support multiple authentication mechanisms including generic OAuth.  The framework works with any API as long as the API on the back-end is:

  1. Accessible by https requests (security policy)
  2. Supports application/JSON content-type on requests
  3. Is either anonymous or supports one of the following authentication models (from Swagger/OpenApi specification):
  • Basic
  • API Key (passed either in the headers or via query string)
  • OAuth2 (access code flow)

I need to inquire about the timeline for OAuth on External Start.  I will get back to you and this thread early next week on that feature specifically.


Hi Tom,

I wanted to get back on the OAuth question specific to External Start.  As we mature our API interface with more functionality, we plan to use OAuth as the authentication mechanism. It’s too early to say for sure if we will tie in External Start. However it is something we would look at closer to the time. No set timeline yet. 


Thanks Dan - that is good to know.


Reply