* Marketing Cloud Engagement *

It is possible to create a journey for this scenario, but you cannot use the standard Marketing Cloud "Forward to a Friend" native feature to automatically inject the referred friend into a brand-new Journey. Because standard FTAF forwards an email on behalf of the subscriber via an encrypted link without capturing the friend's explicit opt-in data or creating a new contact record in your database, it won't natively trigger a separate automated journey.

To achieve this cleanly, you have two primary options. You can build a CloudPage with a smart web form where participants can enter their friend's name and email address, configuring the form submission to write directly to a Data Extension that acts as the entry source for your new hire-introduction journey. Alternatively, you can use personalized referral links within your initial email containing query parameters, directing the friend to a landing page where they opt in and submit their details.

Verify success by submitting a test record through your form or link and checking that the new contact successfully enters the journey and receives the introduction email.

Hi @Dawn Albright,

The one reply so far, joining the _Sent data view with DateDiff > 7, is backwards. That filter keeps anyone who was sent something more than 7 days ago, including people who were also sent something yesterday. You want to exclude anyone with a send in the last 7 days. 

Suppression query (most common approach) 

Run this in Automation Studio and write the result to a "sendable" Data Extension: 

SELECT s.SubscriberKey, s.EmailAddressFROM [YourSourceDE] sWHERE NOT EXISTS (    SELECT 1    FROM _Sent snt    WHERE snt.SubscriberKey = s.SubscriberKey      AND snt.EventDate >= DATEADD(day, -7, GETDATE()))

• The send timestamp column in _Sent is EventDate.
• Send to the output DE, not the original list.
• For a "no more than one email per 7 days" rule, run this query immediately before each send in the same automation. Otherwise the exclusion goes stale.

Alternatives

• Journey Builder: use the same query as the entry source DE, or add a Decision Split on a "last sent date" field that you keep updated.
• Exclusion lists or scripts: these suit a standing "never email these people" rule better than a rolling 7-day window.
• Different lists on different schedules: build one master suppression DE that every send's query checks, instead of coordinating each list separately.

Things to verify, since I haven't checked them against your account

• _Sent only reflects sends in the Business Unit where the query runs. If the two lists send from different BUs, you'd need shared data extensions or a query at the parent level.
• Large _Sent volumes can make this query slow, so keep the date filter in place.
• Sends from outside Marketing Cloud (for example CRM-triggered emails) won't appear in _Sent.

 I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.

Yes, server-to-server Installed Packages are the recommended pattern for headless integrations and they are not subject to the interactive MFA prompts, since they authenticate with OAuth client credentials instead of a username and password. Give each integration its own installed package with only the scopes it needs, and store and rotate the client secrets securely. One thing to watch: keep an eye on the token endpoint responses in your pipelines, because an expired or revoked package shows up as an auth error, not an MFA prompt, and that is what usually breaks pipelines.

Yes — the key point is that there is no supported SQL Data View that directly exposes the MobilePush ContactID → ContactKey mapping.

_PushAddress is essentially a device-level Data View. It gives you _ContactID, _DeviceID, _APID, opt-in status, etc., but not ContactKey. Salesforce has an IdeaExchange request specifically asking for ContactKey to be added to _PushAddress, which confirms this limitation. 

Also, _Subscribers is not a reliable solution. It represents the email subscriber population, so Push-only contacts may not exist there. That's why a join such as:

SELECT ...
FROM _PushAddress p
INNER JOIN _Subscribers s
    ON p._ContactID = s.SubscriberID
WHERE p._OptInStatusID = 2

can return zero rows even though the Contact exists in Contact Builder. 

What you can do with SQL

You can identify the opted-in Push devices:

SELECT
    _ContactID AS ContactID,
    _DeviceID AS DeviceID,
    _APID AS APID,
    _Platform AS Platform,
    _OptInStatusID AS OptInStatusID
FROM _PushAddress
WHERE _OptInStatusID = 2
  AND _Status = 1

If you have multiple MobilePush applications, I would also filter by _APID, because opt-in status is application/device specific. _PushAddress contains device-level records rather than one row per person. 

How to get ContactKey

If you absolutely need:

ContactID → ContactKey

then SQL against the standard Data Views isn't the right mechanism.

The better option is the Marketing Cloud Contacts REST API, which can return both contactID and contactKey for an address. Salesforce's API documentation explicitly exposes both fields for contact addresses and identifies Push as address type 9. 

So the architecture would be:

_PushAddress
    ↓
ContactID + DeviceID + OptInStatus
    ↓
Contacts REST API
    ↓
ContactID → ContactKey

Then write the result into a Data Extension if you need to use it repeatedly in Automation Studio/Journey Builder.

One important distinction

Don't assume:

ContactID = ContactKey

They are different identifiers. ContactID is the system-generated identifier, while ContactKey/SubscriberKey is the business identifier used to aggregate a contact's devices. Salesforce's MobilePush documentation explicitly describes Contact Key as the identifier used to aggregate a contact's devices. 

Bottom line: Your SQL is working correctly. The missing ContactKey isn't because your join is wrong; SFMC doesn't expose the MobilePush ContactID-to-ContactKey relationship through a standard SQL-accessible Data View.

For a complete Push-only population, use the Contacts API (or maintain your own mapping DE from the point where the MobilePush registration/contact key is known). 

Carlota Brejo - if you need any help.. please ping me directly.

@Nagaraju Vadlamudi

Sendlog DE will only show or add records when a send has occurred. 

It is not recommended to update Sendlog DE in any other way. (i.e. using SQL, import etc) 

As you already have the ControlGroup "true" in the source DE, you can apply a filter and run it via automation to review the Control Group audience.  

Additionally, as you have highlighted that you are using "Random Split" in Journey for 10% control group exclusion, I assume that the number of records being processed is >1000, otherwise Random Split may work unexpectedly. See this article for better understanding -

Hi @Ajith M S

Most of these are read-only helpers that sit on top of the SFMC UI, so they're low-risk to try. 

Navigation and discovery 

• SFMC Companion lets you click through Automations, Queries, Data Extensions and more to see where they're saved and what uses them. For example, clicking a Data Extension shows which Queries target it and which reference it in their code. It's the most useful one for untangling an unfamiliar account. Chrome Web Store
• DESelect Search in SFMC is a free extension for finding things that native search handles poorly. Native search only scans one selected folder at a time. It can search across business units or just your current one. The listing carries a note that because of recent Google security updates, it only works if the AppExchange version is already installed, so check that before relying on it. DESelect Search in Salesforce Marketing Cloud - Chrome Web Store +2
• SFMC Scout (recommended in the Trailblazer thread) gives you a side-panel search across Data Extensions, Automations, Journeys, Emails and Content Builder assets.

Development and debugging

• SFMC Inspector (from the thread) covers Data Extension exploration, automation-to-DE mapping, Journey discovery and SQL linting.
• SFMC Dev Studio (from the thread) adds AMPscript/SSJS syntax highlighting, linting, snippets and function references.
• SFMC IntelliType offers AI-powered code completions, snippet management, and contextual assistance for AMPscript, SSJS and SQL. It also includes Data Extension tools for finding and opening a Data Extension quickly without any API configuration. Chrome Web Store Chrome Web Store
• Marketing Cloud  Developer Tools is a DevTools panel. Its features include exposing Publication List IDs and Journey Builder activity keys, showing Data Extension and Journey details, and surfacing more detailed error messages. One reviewer said it doesn't work in their org and another said it's hard to read in dark mode, so test it in your own account. Extpose

Journey Builder and day-to-day admin

• MCX (Marketing Cloud eXtension) covers a lot. It can compare Journey versions and Data Extension configurations side by side, map object relationships visually, and send push notifications directly from Journey Builder. Chrome Web Store
• SFMC Automation Viewer lets you view automation details without pausing active automations. That's handy for checking a live automation. Chrome Web Store
• There's also a Journey Builder email-preview extension that sends previews for every email in a journey at once. I only saw it in Chrome Web Store related-listing snippets, so I don't have its exact name.

Things to check before rolling these out

• Some of these are small third-party tools, and they act with your logged-in SFMC session. Companion notes it's limited by the Marketing Cloud user's roles and permissions, but check each one's requested permissions and privacy disclosures. That matters most on client or production accounts, where you should get sign-off first. Chrome Web Store
• Several of these overlap (Companion, Scout and DESelect all do search), so one or two are usually enough.
• Some listings are old, so confirm each is still maintained before depending on it.
• For serious AMPscript/SSJS work, the Trailblazer answer also suggests Salesforce's AMPscript extension for VS Code. That gives you local development instead of coding in the browser.

 I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.