Running Ads Across Profiles You Control

What you'll be able to do

• Hold an entire artist network in one Business Manager without a permissions hairball
• Run ads AS the artist, AS the fan page, or AS the label - choosing the identity per message
• Keep billing, access, and admin redundancy clean enough that one restriction can't take down the network

The short version: The ecosystem from Module 1 is only useful if you can operate it, and operating it is a permissions architecture problem. The build: one Business Manager holds (or has partner access to) every node - artist pages via Partner access when the artist owns them, fan/HQ/meme nodes owned outright by the operating BM. Ads run from ONE ad account with the identity chosen per message: partnership ads to run as the artist, native identity to run as the nodes you own. DAS 100 Modules 2 and 7 built every tool this module uses; this is those tools assembled into a music operation.

The operator's manual

Module 1 gave you the orchestra. This module is the conductor's stand - and it's unusually mechanical for this track, on purpose. Permissions architecture is exactly the kind of thing that's boring until the day it's the only thing that matters (DAS 100 Module 2's entire thesis, now with an artist's career attached).

Who owns what (the architecture decision)

The question that decides everything downstream: which BM owns which node?

• The artist's main pages: the artist's own BM owns them, always. Even when you're the manager. Even when you built the page. Careers outlast management deals, and the offboarding day is civilized only if ownership was correct on day one. You operate via Partner access (DAS 100 Module 2's flow): advertise + content permissions, minimum viable, in writing.
• Fan / HQ / meme nodes: the operating BM owns them outright. These are marketing infrastructure, not the artist's identity - the team builds them, the team owns them. (What happens to a beloved fan node when the artist changes management is a real conversation - have it at signing, not at exit. The take-home includes the clause language.)
• The two-admin rule applies to the WHOLE network. One hijacked personal profile with admin over the fan node can spray scam ads under names adjacent to the artist's. 2FA on every human, no exceptions, per DAS 100 - the stakes just have a discography now.

Running ads as each identity

One ad account funds everything (clean billing, consolidated learning per DAS 100 Module 4). The identity - whose name and face the ad wears - is chosen per ad:

• As the artist: partnership ads (DAS 100 Module 7's flow). The artist's BM approves the partnership; their handle becomes selectable in your Ads Manager; ads render as them; they see everything and can revoke. The standing rules from Module 7 apply with extra force here - a surprise message under an ARTIST'S name isn't a client complaint, it's a Rolling Stone screenshot. Creative approval flow in writing, always.
• As the owned nodes: native - your BM owns the fan/HQ/meme pages, so they're directly selectable as ad identities. Dark posts from these nodes are where the Module 1 voice matrix becomes paid media: the fan page's testimony, the HQ's news register, each running as ads without cluttering anyone's grid.
• Boosting from the nodes: the boost button remains the amateur entrance (DAS 100 Module 7), with one legitimate exception - flash-boosting a fan-node post that's organically running to capture live momentum, then rebuilding the winner properly in Ads Manager on a stable post ID.

›Go deeper: the identity-per-message routing table

The operational habit that makes the network sing: every campaign brief includes an identity column. Release announce → artist (canon moment, partnership ad). "Best since [older track]" testimony → fan node. Milestone stat → HQ node. Scene-humor angle → meme node. Tour date in a specific market → artist identity, market-geo dark post (DAS 201 Module 5 mechanics). One song's campaign might run 15 ads across four identities from one ad account - to the audience it looks like the whole internet talking about the record; on the backend it's one tidy Business Manager. That gap between how it looks and how it runs is, frankly, the product this track sells.

›Go deeper: comment stewardship across identities

DAS 100 Module 6 made comments part of the ad; the multi-identity version has a twist: the NODES can comment on each other. The fan account replying under the artist's announce ad, the artist liking the fan node's testimony post - cross-node interaction reads as scene energy and compounds every post ID involved. Keep it plausible (the fan node shouldn't reply within 90 seconds of every post like it's on payroll, even though it is) and never fake third-party voices - the nodes ARE team-run and labeled as such; their interactions are the team's public choreography, not sock puppetry. The line from Module 1 holds: labeled nodes interacting is strategy; fake randoms is fraud.

From the field

Inherited setup, real case: artist page owned by an ex-manager's personal profile, fan account logged into via a shared password in a group chat pin, ads running from three different ad accounts with three different cards, one of which belonged to someone's mom. The unwind took a month of polite emails. The rebuild took an afternoon: artist BM owns the canon, operating BM owns the nodes, Partner access bridges them, one ad account, everyone 2FA'd, mom's card retired with honors. Nothing about the music changed; the operation stopped being one bad breakup away from losing the artist's own name.

Common mistakes

• The manager's BM owning the artist's main page (offboarding day will be ugly in direct proportion to this)
• Shared passwords for fan nodes (DAS 100 Module 2 said never; adding a beloved fan account doesn't add an exception)
• Three ad accounts, three cards, zero naming conventions - the learning fragments and so does the billing story
• Partnership ads running artist-identity offers nobody blessed in writing
• Fan node replying to every artist post in 90 seconds like it's on payroll (it is; don't make it obvious)

Take-home

Network Permissions Architecture Sheet - the ownership decision table, the Partner-access request script, the identity routing table template, the at-signing node-ownership clause language, and the offboarding checklist.

Sources & dates

Meta Business Help Center - Partner access, partnership ads (accessed July 2026) · DAS 100 cross-references as cited · architecture model is Darkroom practice, presented as such

Learn more

Optional extra credit. Nothing below is required for the quiz, the certificate, or the job - the full lesson is above. This is for the sickos who want more.

• Meta Business Help Center: partnership ads permission flows - the click-paths, current as of your read date