You are actually testing two requirements here:

• A user who is not logged in should log in when swiping a message preview
• When swiping a message preview, the user should be taken directly to the message

If I was testing this, I would perform the first test as part of a login-feature (which groups the different login/logout scenario’s)

 Scenario: Log in an unauthenticated user opening the application
 Scenario: Log in an unauthenticated user swiping a preview
 Scenario: Log in an unauthenticated user tapping a notification in the bar
 add more here...

And I would test the message preview scenario without dealing with the login or the notification (the origin of the notification, push message, is irrelevant here)

 Scenario: Take user directly to their message on swipe
 Given Dee receives a message preview on her locked phone screen
 When she swipes the preview
 Then she is taken directly to the specific message shown in the preview

This strips both features down to their essentials.

I guess the first scenario should end with a reference to a specificially named second scenario like

...
Then she must "log-in-with-message-from-preview"

(the name should make clear it is not the “usual login”, but a more specific situation).

Now you can describe this 2nd scenario without repeating all the preconditions again:

 Scenario: "log-in-with-message-from-preview"
 Given Dee is at the login 
 And she got a message from a preview before
 Then she is taken directly to the specific message shown in the preview

(Disclaimer: I have no experience with BDD so far.)

To build on the other answers, you could break this down into smaller tests that depend on one another.

Given Dee has received a push notification

This seems to go against the nature of given since receiving is a user interaction. You could write it like this:

Given Dee is sent a push notification

And the first test would be:

Given Dee is sent a push notification
When she receives the notification
Then the message preview appears on her locked phone screen

A second test relies on the first test as a precondition:

Given she is logged out of Uluvit
When she swipes the preview
Then she is taken to the login screen

A third test relies on the second test as a precondition:

When she logs in
Then she is taken directly to the message shown in the preview

There is also an implicit fourth test that relies on the first, but not the second or third:

Given she is logged in to Uluvit
When she swipes the preview
Then she is taken directly to the message shown in the preview

How you rig these tests up to each other will depend on the framework you use. Some frameworks allow nested sections, where the entire scenario is run once for each leaf section, so the entire thing could be written like:

Scenario: Take user directly to their message on swipe

1.  Given Dee is sent a push notification
    When she receives the notification
    Then the message preview appears on her locked phone screen

    2.  Given she is logged out of Uluvit
        When she swipes the preview
        Then she is taken to the login screen

        3.  When she logs in
            Then she is taken directly to the message shown in the preview

    4.  Given she is logged in to Uluvit
        When she swipes the preview
        Then she is taken directly to the message shown in the preview

…and the execution order would be 1, 2, 3 and then 1, 4.

Generally, you rarely see more than 1 “when” in a scenario. The “when” is exercising the behaviour that you’re interested in.

As others have posted, you have two aspects of behaviour here:

• Users must log in before they can access content on the phone
• Users who use a preview will be taken to that preview when they log in.

So you could always have two scenarios.

However, there are a couple of times when it is OK to have two whens (notwithstanding whether your framework deliberately limits you to one or not; some do).

It’s OK to have two whens when you have an interaction between two different stakeholders, or time passes.

In this instance, the behaviours aren’t separated. They’re actually strongly related. One of them is to do with a user who wants to access her phone content, and the other is to do with people who want content to be secure (either the user in another role, or potentially an employer). You can see that from the way the second requirement contains the first.

When you talk to a domain expert about this, they probably won’t separate it when they run through the scenario, either. They might elide the fact that you log in. Either way, it’s perfectly OK to do this as one scenario. You can explicitly have both whens:

When she swipes the preview
And logs in
Then she should be taken directly to the specific message shown in the preview.

If you do decide to go with two scenarios, I would make one of them miss out the fact that she’s logging in, and just do it as part of the step where she accesses the message, both logging in and swiping:

When Dee accesses the message

And then have a separate one which explicitly calls out the security aspect:

When Dee swipes the preview
Then she should be forced to log in before she can view it.

These will actually do the same thing, which makes them redundant, so I’d tend to go with one scenario for pragmatism, and either miss out the fact that she’s logging in (which is fine if it’s obvious) or have two “whens”.

Note that because logging in is an aspect of behaviour that you’re actively interested in, it should definitely be a when and not a then. Lots of people reckon you should only ever have one when, but it’s not how people talk when requirements interact, and BDD was designed to capture conversation, not torture it.