Just-in-time consent: asking at the moment of collection, not all upfront

At a glance

Just-in-time consent asks for each permission at the moment it’s actually needed — when a feature that uses the data is first used — instead of demanding every consent in one wall at signup. It fits India’s DPDP Act well because it makes each request specific and informed: the person understands exactly why you need this data, right when the reason is obvious. It’s the design counterpart to per-purpose consent — ask contextually, one purpose at a time, in context.

Educational resource only. This explains just-in-time consent under India’s Digital Personal Data Protection Act, 2023 (DPDP Act); it is not formal legal advice.

On this page

• What just-in-time consent means
• Why it fits the DPDP Act
• How it differs from consent-at-capture
• How to design it
• FAQ

The situation

The old pattern front-loads everything: a signup screen that asks for all permissions at once — location, contacts, notifications, marketing — before the person has any context for why. Just-in-time flips that: ask for each when its purpose becomes live. It’s better for the user, and it makes each consent more clearly specific and informed.

What just-in-time consent means

Request a permission at the moment the person uses the thing that needs it — not all at once, upfront. Instead of a consent wall at registration, the ask appears in context: your app requests location when the person first opens the map feature; requests contacts when they first tap “invite a friend”; asks about marketing when they’re somewhere it makes sense, not buried in signup. Each request arrives with its reason self-evident, because the person is right there trying to do the thing.

Why it fits the DPDP Act

Contextual asks are naturally more specific and informed — the two qualities consent must have. The Act requires consent to be specific and informed (Section 6), on the back of a clear notice (Section 5). A request made in context does both almost by design: it’s tied to one purpose (specific), and the person understands why because they’re using the feature (informed). A single upfront wall, by contrast, pressures people to agree to everything without context — which produces weaker, less reliable consent. Just-in-time also supports minimisation: you only ask for data if and when the person actually uses the feature that needs it.

How it differs from consent-at-capture

Consent-at-capture is about where you ask; just-in-time is about when. They’re complementary, not the same:

• Consent-at-capture — put the notice and opt-in at the point of collection, not in a buried policy. It’s about location and pairing the ask with the data entry.
• Just-in-time — sequence the asks over time, each when its purpose becomes relevant, rather than all upfront.

Used together: each permission is requested at the right moment (just-in-time) and with its notice right there (at capture). Both serve the same goal — specific, informed, per-purpose consent.

How to design it

Trigger each ask on the action that needs it, keep it to one purpose, and let the person proceed if they decline extras. Design principles:

1. Map permissions to triggers — decide which user action each consent should ride on.
2. One purpose per prompt — don’t re-bundle at the moment of asking.
3. Show the reason inline — a short, plain notice explaining why, right in the prompt.
4. Degrade gracefully — if the person declines a non-essential permission, let them keep using the rest of the product.
5. Don’t nag — repeatedly re-prompting after a decline edges into dark-pattern territory; ask once, respect the answer, offer a clear way to change it later.
6. Record each consent separately, with its context and timing.

FAQ

What is just-in-time consent? Asking for each permission at the moment it’s actually needed — when the person uses the feature that requires the data — rather than demanding all consents upfront at signup.

Is just-in-time consent required by the DPDP Act? The Act doesn’t mandate the pattern by name, but it’s a strong way to meet the specific-and-informed consent standard, because contextual asks are naturally clearer than an upfront wall.

How is it different from consent-at-capture? Consent-at-capture is about where you ask (at the point of collection, not a buried policy); just-in-time is about when (each ask when its purpose becomes relevant). They work together.

What if the user declines a just-in-time request? Let them keep using the parts of the product that don’t need that permission, and offer a clear way to enable it later. Don’t repeatedly nag — ask once and respect the answer.