## TL;DR
Verify the user ID and app ID in the call; E0000007 means one of them does not exist or is not visible to the token. The assignment cannot be created for objects the API cannot see.

## Error
```text
E0000007: Not found: Resource not found: appUser (by id: 00u1234567890abcdef)
```

## Steps
1. Check the user exists and is active: query the user by ID and confirm a 200 with status ACTIVE. Expected: the user resource confirmed.
2. Check the app exists: query the application by ID. Expected: the app resource confirmed.
3. Confirm the API token has permission to read both; a token scoped to a different population or with limited app permissions gets not-found instead of forbidden. Expected: visibility confirmed for both resources.
4. Re-issue the assignment call with the verified IDs. Expected: the assignment is created.

## When to use
- App user assignment returns E0000007
- A provisioning script assigns users in bulk and some fail
- The IDs were copied from another environment

## When not to use
- The error is E0000001 validation (the payload shape is wrong)
- The user or app genuinely does not exist (create it first)
- The assignment exists but provisioning downstream fails (a different problem)

## Tool compatibility
Okta Apps API (all current versions). Behavior is the same for user and group assignments.

### Variant phrasings
### E0000007 when assigning by login instead of ID
Resolve the login to the user ID first; the assignment endpoint needs the ID.

### not found only for users in a specific group
The token's admin role may be scoped to certain groups. Widen the scope or use a less restricted token.

## Why it happens
Okta returns not-found both for genuinely missing resources and for resources outside the caller's visibility. Copy-pasted IDs from another org or tenant are the usual trigger in multi-environment setups.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Nz4hiSUgAx3qT8uYxif4bw