McCrae Tech · Marketing

Marketing GitLab Access — Recommended Setup

Practical, step-by-step recommendations for the GitLab owner and the Entra ID side, based on McCrae Tech's current GitLab structure.

Last updated 2026-06-08

Where things stand today. Marketing has no shared home for its code — assets currently sit under one person's personal area at McCrae Tech > Orchestral > Playground > Personal Projects > Marketing Assets, and only one marketing team member has GitLab access. The goal is a proper shared location for the marketing team, with access granted through an Entra security group (the same way the Orchestral team already works).

Start here — about the group name

There is no "Shared Services" group in GitLab yet — it's a suggested name, not an existing location. Please treat the structure below as a recommendation, not a fixed instruction.

First check whether McCrae Tech already has a suitable top-level group for cross-team work. If it doesn't, create a new one — the final name is yours (or the GitLab admin's) to choose. "Shared Services" is just a suggestion because the group could later hold Sales, Operations, or other non-product teams alongside Marketing.

GitLab side · for Miriam / the GitLab owner

Everything inside GitLab — confirming who owns it, creating the group and repo, mapping access, and migrating the existing assets.

  1. Identify who owns GitLab
    • Find who has permission to create top-level groups under McCrae Tech.
    • Marketing only has limited access today, so this is likely an IT/admin owner — confirm who will own the GitLab-side setup.
  2. Confirm or create the shared group
    • First, check whether a suitable cross-team top-level group already exists. If one does, reuse it and skip to step 4.
    • If not, create a new group at the same level as Orchestral — do not nest it under Orchestral.
    • Suggested name: Shared Services (your call — pick whatever fits McCrae's conventions).
  3. Decide where Marketing sits
    • Recommended: a Marketing subgroup inside the shared group — leaves room for other teams later.
    • Minimum: put Marketing repositories directly under the shared group.
  4. Create the initial repository
    • Example: marketing-assets.
    • This becomes the shared home for HTML pages, scripts, templates, and related assets.
  5. Map access to Jan's Entra group
    • Once Jan sends the group details, add a SAML group link on the shared group (or the Marketing subgroup) mapping Jan's Entra security group to Developer.
    • GitLab matches on the group's Object ID — use the ID Jan provides. Keep it to Developer unless there's a reason for a different role.
  6. Test access
    • Add one marketing user to Jan's Entra group.
    • Confirm they can sign in to GitLab and reach the Marketing area.
    • Confirm they cannot reach Orchestral unless separately authorised.
  7. Migrate the existing marketing assets
    • Move the code currently under Orchestral > Playground > Personal Projects > Marketing Assets into the new repository.
    • This gets it out of a personal area and into the shared team location.

Note: this proposal does not change any existing Orchestral access. Deployment to Cloudflare Pages is handled separately on Jan's side using Wrangler — no GitLab-to-Cloudflare connection is needed (Cloudflare's Git integration doesn't support self-hosted GitLab).

Entra ID side · for Jan

Everything inside Entra ID — the security group, its membership, the enterprise-app assignment, and the details GitLab needs.

  1. Wait for the GitLab target
    • Let the GitLab owner confirm the target group/subgroup before creating anything.
    • You can pre-answer what GitLab needs by inspecting the GitLab enterprise app you already have access to in Entra.
  2. Create the Entra security group
    • Suggested name: GitLab - Shared Services - Developers
    • Type: Security group · Membership: Assigned.
    • Security is required — Microsoft 365 groups can't be assigned to an enterprise app.
  3. Set group ownership
    • Add yourself as owner, plus Miriam or a nominated business owner.
    • Optionally add the GitLab admin as owner if operationally useful.
  4. Add initial members
    • Approved marketing users only, as direct members.
    • Do not add the group to Orchestral access; do not add broader staff unless approved.
  5. Assign the group to the GitLab enterprise app
    • Do this in Entra (you have access). This is what lets GitLab see the group in the sign-in claim.
    • It's safe and additive — members get no GitLab access until the GitLab owner maps the role.
  6. Send the details to the GitLab owner
    • Group display name and Object ID
    • Owners and initial member list
    • Confirmation it's a Security group with Assigned membership, and that it's assigned to the enterprise app
  7. Validate with a test user
    • Add one marketing test user and ask the GitLab owner to confirm access works.
    • Confirm the user only gets Marketing access, not Orchestral.
  8. Document the access model
    • Record the group's purpose, its owners, and who can request membership.
    • Note that access is for the shared GitLab group only.