# Grant customers early feature access without engineering

> Your support team searches for a customer, sees every feature they have switched on, and grants or revokes trial access with an expiry date attached.

- Workflow type: app
- Services: LaunchDarkly, HubSpot, Slack Bot
- Categories: Customer Support, Operations
- Published: 2026-08-31

## What it does

- Search any customer account and see every feature they currently have turned on, which beta groups they belong to, and what is already scheduled to lapse.
- Turn a feature on or off for that one customer from the same row, with a written reason and an expiry date required on every grant.
- Post a note to the feature owner's Slack channel automatically whenever access changes, so product and engineering stay in the loop without being asked.
- Hit Review access and a background assistant sweeps every project and environment, compares what the customer has against their plan and renewal date, and writes a short summary of anything that outlived its trial.

## What you'll need

- A LaunchDarkly account, with permission to change feature targeting for the projects your support team covers
- A HubSpot login where your customer accounts live, ideally with plan tier and renewal date filled in on the company record
- A Slack workspace, plus the channels you want change notes posted to
- A consistent way customer accounts are identified in LaunchDarkly, so a company in your CRM can be matched to its targeting

## Prompt

Build me an internal app that my support and customer success team opens whenever a customer asks for early access to a feature, so nobody has to ping engineering. It is a customer feature access console backed by LaunchDarkly and HubSpot, with change notes going to Slack.

The main screen is a customer search. A rep types a company name or domain and the handler calls HubSpot Search Companies to return matches. Picking an account calls HubSpot Get Company to pull the full record, and the account header shows company name, domain, plan tier, renewal date, and the account owner.

Selecting an account opens the access view for that customer. Use LaunchDarkly List feature flags for the project to get every flag with its per-environment configuration and tags, and Get flag status across environments so a rep can see where a flag is live. For each flag, work out whether this customer is currently switched on and how: an individual context target on the flag, membership in a segment that the flag targets, or the default rule. Use List segments to get the segments in the project and environment, and List segment memberships for context instance to resolve which segments this customer's context actually belongs to. Use Get expiring context targets for feature flag to surface anything already scheduled to lapse.

Render this as one row per feature the customer is on, showing the flag name, the variation they are receiving, how they are getting it (targeted directly, through a named segment, or through the default rule), and the expiry state. Default the whole view to the production environment, with an environment switcher available but production preselected. Include a toggle to show all flags in the project rather than only the ones the customer is currently on, so a rep can grant something new.

From the same row a rep can act. Grant or revoke access for the customer with LaunchDarkly Update flag settings for context, which sets a specific variation for that one context. Add or remove the account from a beta cohort with Patch segment, adding or removing the customer's context key from the segment's included targets. Every grant must also set an expiry through Update expiring context targets on feature flag, so trial access cleans itself up on its own. Suggest a default of 30 days in the date picker but let the rep change it.

Each change posts a note to the feature owner's Slack channel using Slack Bot Send a Message. The note says which customer, which feature, what changed, who made the change, the written reason, and the expiry date. Let an admin map each flag (or each flag tag) to a Slack channel in a settings view, with a fallback channel when no mapping exists, and use Slack Bot List Channels to populate that picker.

Persist every change the app makes: timestamp, the rep who made it, the customer, the flag or segment, the direction (grant or revoke), the reason text, and the expiry date. Show this as an activity log on the account so the next person to open the account can see what was already done and why.

Add a Review access button on the account that kicks off a background agent. The agent sweeps every project and environment for that account using List projects and List environments, then walks the flags and segments in each to build a full picture of what this customer is switched on for beyond the environment the rep happens to be looking at. It reads the HubSpot record with Get Company for plan tier and renewal date. It checks LaunchDarkly List audit log entries to establish who granted what and when, including grants made outside this app. It then writes a short access summary back into the app, attached to the account, calling out grants that outlived their trial, grants with no expiry set at all, grants that contradict the customer's plan tier, and anything worth revisiting before the renewal date. The summary lands in the account view under the flag rows, with a timestamp and a rerun button.

Bake in these rules. Default to production everywhere, and never let a rep act on an environment without seeing which one they are in. Block any flag tagged internal: those rows are visible but locked, with a short note saying why, and no grant or revoke action is available on them. Require a written reason on every grant and every revoke, with the submit button disabled until the reason is filled in, and carry that reason into both the Slack note and the activity log. Show expiry in plain language, like expires in 12 days, expires tomorrow, expired 3 days ago, or no expiry set, rather than raw dates, with the exact date available on hover.

API notes for building this. LaunchDarkly auth is the raw token in the Authorization header with no Bearer prefix, and every request should send LD-API-Version: 20240415. Resources are addressed by human readable projectKey, environmentKey, and featureFlagKey rather than database ids. Targeting changes and toggles are most reliable via semantic patch, which needs Content-Type: application/json; domain-model=launchdarkly.semanticpatch. The API host is region specific and comes from the credential's region field. Expiring context targets are the mechanism behind the expiry date. Standard segments are updated with Patch segment, while big segments need the dedicated big segment target endpoints, so detect which kind a segment is before writing to it.

## How to customize

- Change the default trial length, for example from 30 days down to two weeks, and the wording used for expiry countdowns
- Decide which features are off limits by tagging them internal in LaunchDarkly, and those rows stay locked for everyone using the app
- Pick which environment the app opens on, production by default, and which Slack channel each feature's change notes go to

## FAQ

### Do my support reps need LaunchDarkly seats?

No. The app runs on a single connection to LaunchDarkly, so your support and customer success team work entirely inside the app and never need their own logins or the ability to change anything else.

### Can someone accidentally turn a feature on for everyone?

No. Every change is scoped to the one customer you picked, the app defaults to your production environment rather than guessing, and any feature tagged internal is locked and cannot be granted from the app at all.

### What happens when a trial expires?

Every grant carries an expiry date, and LaunchDarkly removes the customer from the feature's targeting when that date arrives. The app shows the countdown in plain language like expires in 12 days, so nobody has to read a timestamp.

### Where do plan tier and renewal date come from?

From the company record in HubSpot. The app reads it when a rep picks an account, and the review assistant uses it to flag access that contradicts what the customer is actually paying for.

### Can I see who granted what and why?

Yes. The app keeps its own log of every change with the written reason the rep gave, and the review assistant also reads LaunchDarkly's own activity history so you can see grants made outside the app.

Use this prompt in General Input: https://www.generalinput.com/prompts/grant-customers-early-feature-access-without-engineering