Skip to content

Organization settings ​

Organizations have their own page in the dashboard, reached from Organization → Settings in the sidebar. It holds defaults applied to repositories as they arrive, and it is the only settings surface that is not per repository.

The page applies to the organization currently chosen in the organization switcher at the top of the dashboard. Choose one:

  • with All organizations selected, the page says Select an organization in the switcher above to edit its settings;
  • for a personal account, it says Personal accounts don't have organization-level settings. Personal installations have repository settings only.

Who can change them ​

Only admins of that organization. Members see the page with a View only badge and disabled controls, plus the notice You have view-only access to this organization's settings. Ask an admin to make changes. The repository settings page shows the same notice, adding You can still view and trigger reviews.

Changes are drafts until you press Save Changes; Cancel discards them.

Active settings ​

SettingDefaultEffect
Enable review for new repositoriesonDecides the Enable AI review on Pull Requests value a repository starts with the first time it is synced into the dashboard.

Enable review for new repositories ​

This is a default, not a switch. It is read once per repository, when that repository first appears in the dashboard:

  • repositories already in the dashboard are unaffected — their own setting stands, and turning this off does not disable reviews anywhere;
  • a repository that arrives later — you grant the app access to it on GitHub, then it is synced — starts with reviews on or off according to this value;
  • the default itself is on, so an organization that never touches this page gets repositories with reviews enabled, exactly as before.

To change reviews for a repository that already exists, use its own repository settings.

Data retention ​

ControlShown asWhat actually happens
Data retention (days)90Review findings and project-status metadata are deleted after the configured period

The page describes this field as How long review history is kept. EasyMerge automatically deletes review findings and project-status metadata after the configured period. Pull request diffs are processed in memory and are never saved to the database. See Data and privacy.

Members ​

Organization → Members in the sidebar lists everyone linked to the organization's installation: their avatar and display name, GitHub username, email where known, and role. The person who installed the app is tagged · installer.

The installer appears first in the list, followed by other members in username order.

Like the settings page, it needs an organization chosen in the switcher — personal accounts show Personal accounts don't have members.

Roles ​

RoleMay do
AdminChange organization settings, change repository settings, and change other members' roles
MemberView repositories, reviews, and both settings pages — read-only

Membership itself is decided by GitHub, not by EasyMerge: someone appears here once they have signed in to EasyMerge at least once and GitHub reports them as having access to the installation. There is no invite from this page, and no way to remove someone from it — that happens on GitHub.

Who becomes an admin ​

EasyMerge hands out admin by itself only while an organization has none — a fresh install, or one whose admins have all lost access. Whoever owns the account on GitHub claims it:

  • on an organization, anyone with the GitHub role owner becomes an EasyMerge admin the next time they sign in;
  • on a personal account, the account holder.

Installing the app is not what grants it. A member who installs EasyMerge on an organization they do not own joins as a member like anyone else, and an owner who never saw the install screen still becomes admin when they sign in. Once the organization has one admin, everyone who signs in after that joins as a member, and the role dropdown below is the only way to add another.

If EasyMerge cannot read your organization membership from GitHub — the installation has yet to accept the Organization members: read permission — the person who completed the install becomes the admin instead. An owner accepting the permission update on GitHub restores the rule above.

An organization is never left without an admin: if the last one loses access to it on GitHub, the longest-standing remaining member is promoted in their place.

Changing a role ​

Admins get a role dropdown on each member row; picking Admin or Member applies immediately and confirms with username is now admin. Members see roles as static badges under the note Only admins can change member roles.

Two rules constrain this:

  • the installer is always an admin and cannot be changed — their row shows a badge rather than a dropdown;
  • the last admin cannot be demoted. Choosing Member for the only admin left is refused: the dropdown snaps back and the page reads Failed to update member role. Promote a successor first, then demote yourself.

Roles are per installation. You can be an admin of your personal installation and a member of your employer's.