jumo9 (jumo9) asked a question.
Hi,
I have seen the same question for Okta Workflow:
I have a table in Okta Workflow which my Help Desk team will be using. And based on the entries of these tables, the workflows will be running. So I dont think the Delegated flows will also work here. So is there any way of doing this: providing access to Okta Workflow Tables to standard users?
@jumo9 (jumo9) -- No. No method to do this. Access to Workflow Console requires the user be a Super Admin. RBAC functionality is on the roadmap but is not available yet.
As I don't know what your exact use case is it is hard for me to provide suggestions.
>And based on the entries of these tables, the workflows will be running
Why would they need access to the table? Typically, tables are used in one of two ways:
If you need non Super admins to access a value in a table or the contents of the table you could "Send" the table or value to them through a delegated flow delivered as an email attachment or even as something like a Slack message.
@TimL.58332 (Workflows) My use case is: I want to give users temporary access to groups. For which I have written the workflows which will be running on a schedule. To store mapping of user, group and duration, I have created a table as well there. Now the entries in the table will be managed by Help Desk Team. As these requests for giving temporary access will be very frequent and the Help Desk team will just update the table for the user, group and duration part. And I don't want to give them super admin access for this task. Now do you think is there any other way around to achieve this?
@jumo9 (jumo9) - Everything you described could be handled by a Delegated flow to add/update entries in the table and a scheduled flow that runs to remove users. I don't see a reason why these users would even need to directly touch Workflows.
The table would need data points like: TargetUserID, TargetGroupID, DateToBeRemoved + anything else you want to store.
The Delegated flow could then search the table to determine if TargetUserID+TargetGroupID has a match. If matched "update" the found row. If not matched Make a new row.
The scheduled flow (+1 helper) would check the table to see if the DateToBeRemoved has passed. It would then remove the specific user from the specific group. Since you potentially could find multiple results in one check you need to foreach the found rows to a helper to be processed for removal.
@TimL.58332 (Workflows) Yes, Delegated Flows are working. But there is no option of making a field as mandatory. Is there a way to do this?
@jumo9 (jumo9) -- No, you would just need to fail the flow. If I were building something out like this and I had access to Teams or Slack in my environment I would build in input validation at the start of the flow and if the inputs are not in expected formats (or are left empty) I would shoot a "message" to the admin that kicked off the delegated flow since their Okta User ID context is included on the execution. The input validation could be completely done in a Helper flow that just kicks back a "passed validation" T/F. Then "if" false a message along the lines of "Your execution of Delegated Flow X failed to pass input validation. Please ensure all fields were filled out with the expected information"
We use cookies to provide the best website experience and to help understand marketing efforts. We may also share data with ad partners to reach potential customers across the web. To learn more, visit our Privacy Policy. Click here for Your Privacy Choices. You may also opt out of this sharing by signaling your preference via GPC, applicable only to the browser signaling the opt-out.
More information
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work. These cookies do not store any personally identifiable information.
These cookies enable the website to provide enhanced functionality and personalisation. They may be set by us or by third party providers whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly.
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.
These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising.
Select All
We use cookies to provide the best website experience and to help understand marketing efforts. We may also share data with ad partners to reach potential customers across the web. To learn more, visit our Privacy Policy. Click here for Your Privacy Choices. You may also opt out of this sharing by signaling your preference via GPC, applicable only to the browser signaling the opt-out.
More information
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work. These cookies do not store any personally identifiable information.
These cookies enable the website to provide enhanced functionality and personalisation. They may be set by us or by third party providers whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly.
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.
These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising.
Select All
May Okta Community Buzz
Stay ahead of the curve with Okta for AI Agents, new Okta Learning live sessions and labs, shout-outs, and top trending topics—all aimed at enriching your Okta journey.
@jumo9 (jumo9) - Everything you described could be handled by a Delegated flow to add/update entries in the table and a scheduled flow that runs to remove users. I don't see a reason why these users would even need to directly touch Workflows.
The table would need data points like: TargetUserID, TargetGroupID, DateToBeRemoved + anything else you want to store.
The Delegated flow could then search the table to determine if TargetUserID+TargetGroupID has a match. If matched "update" the found row. If not matched Make a new row.
The scheduled flow (+1 helper) would check the table to see if the DateToBeRemoved has passed. It would then remove the specific user from the specific group. Since you potentially could find multiple results in one check you need to foreach the found rows to a helper to be processed for removal.