ArcPy fails to initialize Python 3

[Anonymous User]

When launching a python script from a SQL Server Agent Job I am unable to initialize a product license (We are using ArcPro) which is causing my import arcpy statement to fail. I know its a long shot but do any of y'all have an idea on how to fix this? 

-Ben

[JoeBorgione]

How are you managing your licenses?  It gets a little tricky when using AGOL named users.  I'm curious as to why you are using sql server agent to fire an arcpy script: we have a system user do it, and that system user is also a named user at agol so it can grab the license.

[MichaelVolz]

Is this script gong to be part of an on-going process that will be run as a Windows Scheduled Task?

[JoeBorgione]

Michael Volzl ; all of our scripts run as scheduled tasks not through sql server agent...

[Anonymous User]

So we are running this script after an insert trigger is fired. We currently run it as a scheduled task but have received requests to have it run after records are inserted into a database. We have a named user license that is authorized to work offline on the machine.

[JoeBorgione]

I don't know how you would convince the license part that sql server agent is the same as the user name that runs your scheduled tasks. That's a funky one.

Would you consider an attribute rule that fires upon insert?

[Anonymous User]

I would. Can you provide documentation for me to go down that rabbit hole? I really appreciate the help. 

[MichaelVolz]

Is this an enterprise geodatabase?  If so, would that require that the Attribute Rule be run against a feature service where the enterprise geodatabase is the source?

[Anonymous User]

It is an enterprise gdb yes. As for your second question technically I think so?

[JoeBorgione]

Attribute rules:  Introduction to attribute rules—Geodatabases | Documentation 

 would that require that the Attribute Rule be run against a feature service where the enterprise geodatabase is the source?

Any attribute rule(s) are assigned to a specific attribute in the specific feature class.  I believe if that feature class is a published, editable feature layer/service the attribute rules are fired back in the enterprise gdb, so you'd be good to go.