Named User Vs Generic

ppatel
New Contributor

Out of curiosity, are there any folks out there that have opted to have some "Generic" users/licenses versus specific named users in their environments? A couple of places where I think a generic would be relevant is when giving auditors view only access to the application. If there is a team of 3-4 auditors who need view only, would it not make sense to just create 1 generic user?

On the flip side, what are big reasons people choose to go the named user route besides the obvious ones of audit trail for data loads and form completions and workflows?

Just trying to get an idea of how popular generic users truly are when I personally have only seen the named user route. 

1 ACCEPTED SOLUTION

MikeG
Contributor III

Hi @ppatel , It's also best practice to not have Task Scheduler run with a contractor or employee ID.  i.e. an implementation partner configuring automated tasks should use a generic ID like OS_Automation or SVC_OneStream (when setting up Task Scheduler tasks) as a Native account that will never be disabled.  I see that a lot.  Jobs setup on the Task Scheduler with a named individual that is only there for the implementation and not a permanent, long term individual working in the app.

For auditors, I'd err on the side of not letting them "in", just extract out what they think they need and hand it over in a PDF or Excel file.  Creating temporary accounts for auditors may not align with a customers security policy.

Hope that helps, interested in others experience and potential use cases for generic ID usage.

 

View solution in original post

2 REPLIES 2

MikeG
Contributor III

Hi @ppatel , It's also best practice to not have Task Scheduler run with a contractor or employee ID.  i.e. an implementation partner configuring automated tasks should use a generic ID like OS_Automation or SVC_OneStream (when setting up Task Scheduler tasks) as a Native account that will never be disabled.  I see that a lot.  Jobs setup on the Task Scheduler with a named individual that is only there for the implementation and not a permanent, long term individual working in the app.

For auditors, I'd err on the side of not letting them "in", just extract out what they think they need and hand it over in a PDF or Excel file.  Creating temporary accounts for auditors may not align with a customers security policy.

Hope that helps, interested in others experience and potential use cases for generic ID usage.

 

Exactly as Mike mentioned, we have a "TaskScheduler" native ID which is the only non-specific user set up in our app. We also don't provide access to our auditors. Requests go through the admin, aka me 🙂