organizations

Subscribe to all “organizations” posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

→ ~ cd github-changelog
→ ~/github-changelog|main git log main
showing all changes successfully

Replacement of announcement banner GraphQL fields

Announcement banner fields in GraphQL for enterprises and organizations are being replaced with a new announcementBanner object to simplify their access and better follow our standard styles. The new fields are available today, and the old fields will be removed on April 1, 2025.

The following fields are being removed from the enterprise and organization GraphQL objects:

  • announcement
  • announcementCreatedAt
  • announcementExpiresAt
  • announcementUserDismissible

The new GraphQL structure for these fields is:

announcementBanner {
  message
  createdAt
  expiresAt
  isUserDismissible
}

Learn more about announcement banners for organizations on GitHub Enterprise Cloud.

See more

View an organization’s REST API activity with API insights in public preview

As a GitHub Enterprise Cloud organization owner, you and your designated users can now use API insights to visualize REST API activity for your entire organization or specific apps and users. This new feature, currently in public preview, helps you understand the sources of your REST API activity and manage against your primary rate limits—giving you visibility into the timeframe, apps, and API endpoints involved.

Who can access it

The API insights feature is available only at the organization level. By default, only organization owners can access it. However, organization owners can grant access to non-owners by creating a custom role at the organization level, assigning the permission named View organization API insights to the custom role, and then assigning the custom role to an organization member or team. See the documentation for managing organization custom roles.

Where to find it

The API insights public preview feature is enabled for all GitHub Enterprise Cloud organizations. To access it on your organization home page, select Insights near the top of the page, and then select REST API on the left side of the page.

An image of an organization homepage where selecting Insights and then REST API will navigate to the new API insights feature.

How to use it

Use the Period and Interval drop-downs to choose the range of time displayed in the chart and how granularly to display REST API requests on the chart. These drop-downs also set the time range for the “Total REST requests,” the “Primary-rate-limited requests,” and the Actors table below the chart.

An image of the API insights feature page showing the Period drop-down expanded for selecting the time period of REST API activity to include.

The Actors table displays the GitHub Apps and users that made REST API requests in the current organization within the selected time period. Select a GitHub App to display its REST API activity and any primary-rate-limiting. Select a user to display their personal REST API activity from personal access tokens (PATs) and OAuth apps acting on their behalf.

An image of the API insights feature page showing a table of actors, including GitHub Apps and users, that created REST API activity in the selected time period.

Tell us what you think

We welcome your feedback in this community discussion.

Refer to the documentation for API insights for more details about understanding your organization’s REST API activity and investigating primary-rate-limiting.

See more

Add repository permissions to custom organization roles

You can now add repository permissions to custom organization roles, granting a specific level of access to all the repositories in your organization.

This builds on the release of organization-wide permission grants in GitHub’s pre-defined organization roles. These updates enable admins to easily scale access management across large teams and organizations.

Creating a custom organization role using the new repository permissions. The role is based on the Write base role, and adds 3 permissions - delete issues, request solo merge, and update repo properties

Using repository permissions in organization roles

Organization roles do not have to contain organization permissions (i.e. read_org_audit_log) in order to include a repository role and permissions (i.e. close_issue). This lets you create your own versions of the pre-defined organization base roles like Write or Triage, assigning those roles to everyone in your organization to ensure a set standard of access that matches your requirements.

A popular use case is to create elevated roles for your on-call rotation. For instance, a role based on Write with the “Jump the merge queue” and “Request a solo merge” repository permissions added so that your on-call team can get that fixed quickly. Using the APIs you can automate assignment of this role to your current on-call, granting them those elevated permissions as a break-glass or shift-based privilege.

Managing repository access

Both the UI for organization role creation and the REST API have been updated to support repository permissions.

In addition, we’ve updated the repository access management page to distinguish between access granted by the repository owner to a user or team versus organization-wide grants made by the organization owner. This helps explain how a user got access to a specific repository.

The new repository collaborators view, showing the organization based access.

For more information, see GitHub’s documentation as well as the REST API methods for automating role creation and assignment.

See more

Pre-defined organization roles that grant access to all repositories

Organization owners can now grant a user or team access to all of the repositories in their org with a single click. Five new pre-defined roles have been added to the organization settings, under Organization Roles > Role Management, where all organization owners can view and assign them.

Pre-defined roles ship natively with GitHub. We will add more pre-defined roles over time that support common personas like “CI/CD Admin” or “Security Manager”.

A screenshot showing the five new roles in the organization settings

Introducing pre-defined roles and organization-wide repository permissioning

These five new roles showcase an expansion of organization roles – the ability to also include repository-level base roles (like read) and permissions (like close issue). When granted, the recipient has those privileges on all of the repositories in the organization, current and future. While organization owners cannot yet create organization roles that include repository permissions, that will be supported in the coming months.

A screenshot of the Triage role expanded to show the repository permissions included in the role

This new functionality of organization roles helps organizations replace automation that watches for new repository creation and adds the right users or team to every repository.

UI updates to show role assignments

When users and teams are assigned access across all repositories, this is called out in the team and repository view rather than list all of the accesses.

A screenshot showing that this team has access to all of the repositories in the organization. Below it is a listing of the repositories that the team has been given specific access to.

In addition, the Roles Management view in the organization settings has been updated to show indirect assignments – these are roles that a user or team recieves due to a team that they are a member of. This provides a full accounting of all organization roles that a user or team has within the organization.

A screenshot showing a user that has been granted two roles. One is directly assigned, and has a remove button on the right hand side of the row. The other is indirectly assigned via a team named org-member-parent-team, and does not have a remove option.

The APIs for organization role management have been updated to support these pre-defined roles. You’ll find a base_role field in the description of the organization role, which is the repository role (like read) that is included in the organization role.

You can learn more about organization roles at “Using organization roles“.

See more

Compliance Reports for Free and Team Organizations

All organization owners now have access to a Compliance tab within their organization’s settings page. This page has been available for all organizations on the GitHub Enterprise plan, but is now extended to organizations on the Free and Team plans as well.

To access the latest compliance and certification reports for your organization, navigate to https://github.com/organizations/<yourorganization>/settings/compliance. The reports you can expect to see for an organization on a Free or Team plan will be SOC 3, ISO/IEC 27001:2013 certification, and CSA CAIQ.

To learn more, read about accessing compliance reports for your organization.

 

See more

Organization Archiving general availability

Building on the Public Beta of organization archiving, we're excited to announce that organization archiving is now generally available.

You can now archive all repositories in an organization with a single click. Archiving an organization will:

  • Archive all repositories in the organization
  • Set a key in the API to indicate the org has been archived
  • Restrict activities in that organization such as creating new repos
  • Display a banner on the organization's profile indicating that it's been archived
  • Email the organization's owners to let them know that the organization has been archived

To archive an organization, go to the organization's settings page and click the "Archive organization" button in the Danger Zone. This will launch a background job which performs the archiving; once complete, the banner will show up on the organization's profile page.

For more information on organization archiving, including how to un-archive an organization, see "Archiving an organization"

We'd love to hear your feedback on how it works for you.

See more

2FA requirement status on the People pages

As part of the two-factor authentication requirement program on GitHub.com, the People pages of enterprises and organizations have been updated to include the 2FA requirement status of members and collaborators. As an administrator, you can see which of your users have not yet enabled 2FA but are required to do so because of an action they have take in one of your organizations, or elsewhere on GitHub.com.

A clock icon will appear as a user's 2FA status will show if the user is required to enable 2FA. When the icon is red, they are past the due date for enabling 2FA, and are at risk of being blocked from accessing GitHub.com until they enable it. Clicking the clock icon will display the user's enrollment date.
256704235-eb7cb75d-2806-4aa6-aa44-aa9148bfb828

You can filter the UI to show only users who have a pending requirement. Enrollment dates are also now included in the CSV and JSON downloads of enterprise and organization memberships.

To learn more about the 2fa enrollment program, see our blog post with more details. For information about viewing your members, see the organization and enterprise documentation.

See more

More love for innersource collaboration and enterprise fork policies

In June 2022 we updated fork capabilities to include forking a repository into the same organization as its upstream repository, forking internal repositories to enterprise organizations, and for enterprise owners to limit where forks can be created. This opened up a lot of new possibilities for collaboration!

We recently updated fork capabilities again to unblock an additional workflow: fork repositories into another organization more than once. Before, when you tried to fork a repository into another organization that already had a fork of that repository, your option to finish forking into that organization was grayed out and GitHub let you know that a fork already exists in the target organization. With this update, you will have the option to continue forking it using a unique name.

screenshot of forking when the repo already exists and has a red warning triangle

screenshot of forking when the fork has been renamed and has a green check

We welcome your feedback on this in GitHub’s public feedback discussions.

See more

Invitation Enhancements

In the spirit of continuing to improve our invitation experience, we are bringing a few more enhancements to the UI and APIs to better support invitation management experiences. From today onward, the following will apply:

  • Enterprise owners can view all failed user invitations across their enterprise;
  • Enterprise and Organization owners can take bulk actions on their corresponding "People" pages in order to delete or retry failed invitations;
  • Outside collaborators will now be reflected within the failed invitation pages;
  • Enterprise owners can add multiple existing enterprise members to organizations via the UI at https://github.com/enterprises/<enterprise>/people; and
  • Invitation pages within organization and enterprise "People" pages will display invitation source information.

To learn more, read about inviting users in an organization.

See more

Organization Invitation Improvements

Whether you invite a user to an organization via the API or via our user interface, we are bringing enhancements to make this experience better. From today, you can:

  • search for a user via a verified email address both within the API and on an organization’s “People” pages;
  • utilize the API to assign more than one enterprise member at a time to additional organizations within your enterprise;
  • view additional user information provided within the enterprise and organization “People” invitation pages.

To learn more, read about inviting users in an organization.

See more

Org admins can disable integration requests from outside collaborators

Organization administrators are now able to prevent outside collaborators from requesting the installation of both GitHub and OAuth apps to their organization. The "Allow integration requests from outside collaborators" setting can be found under Organization Settings > Member Privileges > Integration installation requests. This setting is enabled by default, and disabling it prevents outside collaborators from making app installation requests, unless the app has already been approved for use within the organization.

integration-installation-requests-setting

On the app integration page, organizations that do not permit installation requests will be disabled.

disabled OAuth integration installation page

Learn more about outside collaborators permissions in our documentation, "Setting permissions for adding outside collaborators".

See more

Enterprise fork policies for organizations

Previously, we announced the ability for enterprise owners to limit where private and internal repository forks can be created. We heard from some customers that they need a more granular control over fork permissions for each organization within the enterprise.

Now, we've added the ability for enterprise organization admins to set fork policy at the organization level, further restricting enterprise policy. Forking can be limited to organizations within the enterprise, within the same organization, user accounts and organization within the enterprise, user accounts, or everywhere. Fork policies cascade from the enterprise policy to organization policy to repository policy. Enterprise policies dictate the policy options available for organizations, i.e. an organization admin can only set a more restrictive forking policy than the enterprise allows.

Screenshot of organization fork policy settings

See more
View more changes