Authentication, Permissions, and Security
Alteryx Server supports built-in authentication and integrated Windows authentication, plus SAML/SSO in many configurations. Users are organized into roles (Curator, Artisan, Viewer and their custom equivalents) and districts (groups that control who can see and run which workflows). Permissions are layered: a user's role sets baseline capabilities, while workflow-level sharing and collection membership determine access to specific assets. Collections group workflows and assign access to users or districts.
The security surface includes: the service account (privileged, should not be a user's daily account), API keys and OAuth for programmatic access, SSL for data in transit, and encryption at rest for sensitive credentials stored in workflows. Workflows that store database passwords embed them in the workflow-protecting the persisted workflow directory matters. Run As settings let a schedule execute under a specific user's credentials, which has security and permission implications.
Traps: confusing role with district (role = what you can do; district = what you can see/run); assuming a Curator can see every workflow regardless of sharing; forgetting that removing a user does not automatically clean up their schedules and credentials; and treating API keys as user passwords (they are separate secrets with their own scopes).
Worked example: A user can open the Gallery but cannot run a workflow. Check role (Viewer cannot execute in the same way as Artisan), then workflow sharing/collection membership, then whether the workflow requires credentials the user lacks. Diagnose from broadest (role) to narrowest (workflow credentials).
Rule of thumb: authentication answers who you are; authorization answers what you can do and see-questions often test the boundary between role and district.