Project administration practices and troubleshooting
Good project administration is mostly about standardisation and controlled change. Build projects from templates, reuse shared schemes rather than cloning configuration per project, adopt naming conventions and project categories so projects can be found, and delegate day-to-day work through the Administer Projects permission instead of global administration. Archive or trash projects rather than deleting them outright, and know the recovery window before promising data back.
Troubleshooting should be systematic rather than guesswork. Define the symptom - cannot see an issue, cannot transition, field missing, board empty, no notification - then walk the layers in order: global permission, project permission scheme and role membership, issue security level, workflow condition or validator, field configuration and screen, and finally the board or filter. The audit log, permission helper and mail diagnostics support this. In Cloud there is no self-service backup and restore comparable to Server; use a sandbox or export for change testing and rollback planning.
Traps: assuming a shared scheme edit is scoped to one project; assuming deleting an issue type or custom field cleans up all references; assuming team-managed and company-managed projects behave identically during migration; and testing changes directly in production. Migrating from team-managed to company-managed uses a one-way assistant that maps access roles to permission schemes and must be verified afterwards.
Rule of thumb: reproduce the change in a small test project or sandbox first, then apply it to the shared scheme.