Beta Access

Beta Access

Eclipse sometimes opens new workflows through invited beta access before they widen to every workspace. This keeps the rollout controlled while product and support learn from real usage.

Behind the scenes, Eclipse can widen or pause invited beta waves with server-side rollout flags. That lets the team expand access carefully, pause a rollout quickly, and keep beta behavior targeted to the invited cohort.

What To Expect

• beta access is invitation-based
• the workflow may still change quickly
• availability can expand, narrow, or expire during the rollout
• support may ask for feedback before the workflow becomes generally available

Redeem A Beta Code

1. Open the invited workflow in Eclipse.
2. Enter the beta code from your invitation.
3. Confirm the workspace that should receive access.
4. Start with the core workflow first so you can tell whether it is ready for your real use case.

Keep These Codes Separate

• Beta code: unlocks access
• Public issue reference code: helps support trace a bug and looks like ERR-XXXXXX

If you report a bug, send the ERR-XXXXXX code. If you need help getting in, send the beta code. Support moves faster when those stay separate.

Need More Time?

If your beta window is about to end and you still need access:

1. Contact support before the end date.
2. Share the workspace and beta code.
3. Explain whether you need more time for onboarding, validation, or issue follow-up.

Support may extend your access or apply a manual override when that is the safest path.

Share Better Feedback

The most useful beta reports include:

• what you were trying to do
• what happened instead
• what you expected
• any ERR-XXXXXX public issue reference code you saw

That gives support and product enough context to triage the issue without confusing it with your access status.