Skip to content
Integrations LaunchDarkly

LaunchDarkly + Finn.

LaunchDarkly integration with Finn. LaunchDarkly manages feature flags, software releases, and product experiments.

What you can do with LaunchDarkly.

LaunchDarkly manages feature flags, software releases, and product experiments.

Roll out a feature in measured stages

Finn takes a release from its initial audience to the agreed rollout while checking the effect of each targeting change.

Typically handled byRelease engineer

Starts when

A tested feature is ready for the release owner's agreed rollout plan.

What Finn handles

  1. Read the flag, audience rules, release decision, and health criteria for each rollout stage.
  2. Submit the required targeting approval and apply the first accepted change in LaunchDarkly.
  3. Check the feature's behavior and connected Datadog health signals before advancing to the next agreed stage.
  4. Finish the rollout, record the final audience and verification results, and update the release issue in Jira.

The result

The feature reaches its intended audience with the rollout decisions and observed results recorded.

Turn off a feature causing an incident

Finn applies the incident's authorized feature rollback and verifies whether it restores the affected customer journey.

Typically handled byOn-call release engineer

Starts when

A newly enabled feature is linked to a service incident.

What Finn handles

  1. Connect the incident evidence to the flag change and identify the previous working variation.
  2. Use the incident's rollback authorization or obtain the release owner's decision before changing production targeting.
  3. Restore the selected variation and check the affected journey and Datadog signals.
  4. Update the PagerDuty incident and create the corrective GitHub issue with the flag and recovery evidence.

The result

The incident records the feature rollback's actual effect and the work needed before another release.

Enable a customer's accepted feature request

Finn applies an accepted customer targeting change and confirms that the intended account receives the feature.

Typically handled byTechnical account manager

Starts when

An account owner approves a customer's access to a feature already controlled by a flag.

What Finn handles

  1. Read the customer record in connected Salesforce and confirm the accepted account and feature scope.
  2. Match the account to the application's LaunchDarkly targeting context and current variation.
  3. Complete any required flag approval, update the targeting rule, and verify the resulting feature behavior.
  4. Send the customer the activation instructions through the support system and record the completed request.

The result

The accepted customer account receives the feature and the request records the targeting change and confirmation.

Complete a scheduled feature launch

Finn prepares and follows a time-sensitive flag change so the launch happens with a clear record of its result.

Typically handled byLaunch coordinator

Starts when

A feature must become available at an agreed event time.

What Finn handles

  1. Read the release plan, target environment, audience, and exact launch time with its time zone.
  2. Create the scheduled flag change and complete the release owner's approval requirements.
  3. At launch, read the change result and check the intended feature behavior through the connected application test.
  4. Publish the launch update in Slack and attach the result to the release issue, acting on a failed change through the release procedure.

The result

The scheduled launch has a verified targeting result and an accurate announcement.

Carry an experiment through its decision

Finn coordinates an accepted product experiment, assembles its measured results, and applies the product owner's resulting feature decision.

Typically handled byProduct analyst and experimentation coordinator

Starts when

A product owner accepts an experiment hypothesis, audience, measures, and stopping criteria.

What Finn handles

  1. Set up the experiment and flag variations in LaunchDarkly, then obtain the experiment's launch approval.
  2. Start the accepted iteration and follow its agreed duration and health criteria.
  3. Read the experiment's collected business measurements from connected Snowflake and publish the analysis with its limits.
  4. Record the product owner's decision, apply the accepted feature targeting, and close the experiment's Jira work.

The result

The experiment ends with documented evidence and an implemented product decision, without inventing a winning result.

Retire a flag after a finished rollout

Finn removes obsolete flag handling from the code and completes the flag's retirement after the feature owner accepts the permanent behavior.

Typically handled byMaintenance engineer

Starts when

A fully released feature no longer needs its temporary rollout flag.

What Finn handles

  1. Read the flag's usage and repository references and confirm the permanent behavior with the feature owner.
  2. Remove the obsolete branches through connected GitHub and test the application behavior.
  3. Carry the code change through review and release, confirming the deployed application no longer needs the flag.
  4. Archive the retired flag and record the code, release, and retirement result on the maintenance issue.

The result

The temporary flag is retired after its application dependency is removed and verified.

Investigate an unexpected targeting change

Finn traces a reported difference in feature access to the targeting configuration and completes the owner's chosen correction.

Typically handled byRelease operations engineer

Starts when

A customer or tester receives an unexpected feature variation.

What Finn handles

  1. Read the affected context, environment, targeting rules, and linked release decision.
  2. Compare the observed behavior with the account's intended audience and identify the specific mismatch.
  3. Get the release owner's correction decision, then update the flag through its required approval process.
  4. Verify the account's feature behavior and update the support case with the correction and cause.

The result

The reported targeting problem is resolved with the exact change and verification attached to the case.

Set up the connection around your work.

Contact Finn to discuss the records your workflow needs and the actions you want it to perform.

Your team chooses what Finn can access, what agents can change, and when a person must approve the work. The connection needs the appropriate account access and permissions from LaunchDarkly.

Visit LaunchDarkly

Put your LaunchDarkly integration to work.

Tell us which records, actions, and teams the connection needs to support.