Feed

@HARIPRASAD Km I don't believe there is a way to achieve 100% without changing the class... first - emailLimit will never be null, so you will not get into that block. There is also no way to set org limits from a test, so the 'close to limit' and 'at limit' branches are not going to hit. I also don't see anyway you would end up in the catch block - nothing in here would fail.

There are some things you can do to refactor that could help, but you'd essentially just be making the changes to get higher coverage, when you could easily get the 75% keeping the class as is. Regardless, if that is your goal, I'll try to help:

 The problem is this line:

Map<String, System.OrgLimit> limits = System.OrgLimits.getMap(); 

The class fetches those numbers itself, so a test can’t get in between. Flip it around - define a small interface with getDailyLimit() and getEmailsUsed(), put the System.OrgLimits call in one class that implements it, and hold that in a @TestVisible private static field on the controller. Production uses the real one by default, and your test reassigns the field to a mock. Your if/else logic doesn’t change at all. 

From there 5000/4995 hits “almost reached”, 5000/5000 hits exceeded, 5000/100 hits the normal path, nulls hit “unable to retrieve”, and a mock whose getter throws hits the catch. Keep one test that doesn’t swap the provider so the real one gets covered too.

Here are the classes: 

public with sharing class SingleEmailLimitController {
    public class EmailLimitResponse {
        @InvocableVariable(label='Daily Single Email Limit')
        public Integer dailyLimit;
        @InvocableVariable(label='Emails Used')
        public Integer emailsUsed;
        @InvocableVariable(label='Emails Remaining')
        public Integer emailsRemaining;
        @InvocableVariable(label='Limit Status Message')
        public String statusMessage;
    }
    public interface LimitProvider {
        Integer getDailyLimit();
        Integer getEmailsUsed();
    }
    public class OrgLimitProvider implements LimitProvider {
        public Integer getDailyLimit() {
            System.OrgLimit l = System.OrgLimits.getMap().get('SingleEmail');
            return l == null ? null : l.getLimit();
        }
        public Integer getEmailsUsed() {
            System.OrgLimit l = System.OrgLimits.getMap().get('SingleEmail');
            return l == null ? null : l.getValue();
        }
    }
    @TestVisible
    private static LimitProvider provider = new OrgLimitProvider();
    @InvocableMethod(
        label='Check Single Email Limit'
        description='Checks daily email usage and returns a status message.'
    )
    public static List<EmailLimitResponse> checkSingleEmailLimit(List<String> requests) {
        List<EmailLimitResponse> results = new List<EmailLimitResponse>();
        if (requests == null || requests.isEmpty()) {
            return results;
        }
        EmailLimitResponse evaluated = evaluate();
        for (Integer i = 0; i < requests.size(); i++) {
            EmailLimitResponse r = new EmailLimitResponse();
            r.dailyLimit = evaluated.dailyLimit;
            r.emailsUsed = evaluated.emailsUsed;
            r.emailsRemaining = evaluated.emailsRemaining;
            r.statusMessage = evaluated.statusMessage;
            results.add(r);
        }
        return results;
    }
    @TestVisible
    private static EmailLimitResponse evaluate() {
        EmailLimitResponse result = new EmailLimitResponse();
        try {
            Integer dailyLimit = provider.getDailyLimit();
            Integer emailsUsed = provider.getEmailsUsed();
            if (dailyLimit == null || emailsUsed == null) {
                result.statusMessage = 'Unable to retrieve the daily email limit.';
            } else {
                result.dailyLimit = dailyLimit;
                result.emailsUsed = emailsUsed;
                result.emailsRemaining = Math.max(0, dailyLimit - emailsUsed);
                if (emailsUsed >= dailyLimit) {
                    result.statusMessage =
                        'Daily email limit exceeded. No email capacity remains.';
                } else if (result.emailsRemaining <= 10) {
                    result.statusMessage =
                        'Daily email limit almost reached. Only ' +
                        result.emailsRemaining + ' emails remaining.';
                } else {
                    result.statusMessage =
                        'Email capacity available. ' + result.emailsRemaining +
                        ' emails remaining out of ' + dailyLimit + '.';
                }
            }
        } catch (Exception e) {
            result.statusMessage = 'Unable to check email limit: ' + e.getMessage();
        }
        return result;
    }
}

And Test Class

@IsTest
private class SingleEmailLimitControllerTest {
    private class MockException extends Exception {}
    private class MockProvider implements SingleEmailLimitController.LimitProvider {
        private Integer dailyLimit;
        private Integer emailsUsed;
        private MockProvider(Integer dailyLimit, Integer emailsUsed) {
            this.dailyLimit = dailyLimit;
            this.emailsUsed = emailsUsed;
        }
        public Integer getDailyLimit() { return dailyLimit; }
        public Integer getEmailsUsed() { return emailsUsed; }
    }
    private class ThrowingProvider implements SingleEmailLimitController.LimitProvider {
        public Integer getDailyLimit() { throw new MockException('simulated failure'); }
        public Integer getEmailsUsed() { return null; }
    }
    private static List<SingleEmailLimitController.EmailLimitResponse> run() {
        return SingleEmailLimitController.checkSingleEmailLimit(new List<String>{ 'go' });
    }
    @IsTest
    static void limitUnavailableReturnsMessage() {
        SingleEmailLimitController.provider = new MockProvider(null, null);
        Test.startTest();
        List<SingleEmailLimitController.EmailLimitResponse> results = run();
        Test.stopTest();
        Assert.areEqual(
            'Unable to retrieve the daily email limit.',
            results[0].statusMessage
        );
        Assert.isNull(results[0].dailyLimit);
    }
    @IsTest
    static void limitExceededReturnsMessage() {
        SingleEmailLimitController.provider = new MockProvider(5000, 5000);
        Test.startTest();
        List<SingleEmailLimitController.EmailLimitResponse> results = run();
        Test.stopTest();
        Assert.areEqual(0, results[0].emailsRemaining);
        Assert.isTrue(results[0].statusMessage.contains('limit exceeded'));
    }
    @IsTest
    static void almostReachedReturnsMessage() {
        SingleEmailLimitController.provider = new MockProvider(5000, 4995);
        Test.startTest();
        List<SingleEmailLimitController.EmailLimitResponse> results = run();
        Test.stopTest();
        Assert.areEqual(5, results[0].emailsRemaining);
        Assert.isTrue(results[0].statusMessage.contains('almost reached'));
    }
    @IsTest
    static void capacityAvailableReturnsMessage() {
        SingleEmailLimitController.provider = new MockProvider(5000, 100);
        Test.startTest();
        List<SingleEmailLimitController.EmailLimitResponse> results = run();
        Test.stopTest();
        Assert.areEqual(4900, results[0].emailsRemaining);
        Assert.isTrue(results[0].statusMessage.contains('Email capacity available'));
    }
    @IsTest
    static void exceptionIsCaught() {
        SingleEmailLimitController.provider = new ThrowingProvider();
        Test.startTest();
        List<SingleEmailLimitController.EmailLimitResponse> results = run();
        Test.stopTest();
        Assert.isTrue(results[0].statusMessage.startsWith('Unable to check email limit:'));
    }
    @IsTest
    static void outputSizeMatchesInputSize() {
        SingleEmailLimitController.provider = new MockProvider(5000, 100);
        Test.startTest();
        List<SingleEmailLimitController.EmailLimitResponse> results =
            SingleEmailLimitController.checkSingleEmailLimit(
                new List<String>{ 'a', 'b', 'c' }
            );
        Test.stopTest();
        Assert.areEqual(3, results.size());
        Assert.areEqual(4900, results[2].emailsRemaining);
    }
    @IsTest
    static void emptyInputReturnsEmptyList() {
        Test.startTest();
        List<SingleEmailLimitController.EmailLimitResponse> results =
            SingleEmailLimitController.checkSingleEmailLimit(new List<String>());
        Test.stopTest();
        Assert.areEqual(0, results.size());
    }
    @IsTest
    static void realProviderReturnsAResult() {
        Test.startTest();
        List<SingleEmailLimitController.EmailLimitResponse> results = run();
        Test.stopTest();
        Assert.areEqual(1, results.size());
        Assert.isNotNull(results[0].statusMessage);
    }
}

Let me know if this all makes sense. Happy to talk through it more

Hello @Maria Mittleman

are they coming from an API Call or manually created/assigned? 

Please have a look at this help article on "Assignment rules do not send notification emails for Leads or Cases created via API" :

Eric

The three tools solve the same problem (moving metadata between orgs) at different levels of maturity, so the practical answer is to pick based on team skills and how much control you need. 

1. Change sets (declarative, org-to-org) 

• You select components one at a time in the source org, upload to a connected org, then validate and deploy in the target.
• It’s fine for a one-off tweak or an admin-only team.
• Change sets don’t work with the Salesforce CLI or source-driven development in general, so nothing lands in version control. Salesforce isn’t planning further enhancements to them, and DevOps Center is positioned to replace them. 
• Common pain points: you rebuild the component list for every hop, there’s no easy rollback, and large change sets are hard to troubleshoot.

2. Salesforce CLI (code-first, source-driven)

• Keep metadata in Git as the source of truth. Develop in scratch orgs or sandboxes, and use sf project retrieve start and sf project deploy start to move changes.
• Validate before deploying (--dry-run) and run specified tests (--test-level RunSpecifiedTests) so deployments stay fast and safe.
• Wire it into CI/CD (GitHub Actions, GitLab CI, Jenkins, Azure DevOps): run tests on pull requests, deploy to the integration sandbox on merge, then promote to UAT and production.
• Use delta deployments (for example the sfdx-git-delta plugin) to deploy only what changed, and use sf org login jwt with a connected app for non-interactive authentication.
• This gives the most control and the best auditability, but it requires developers who are comfortable with Git and the command line.

3. DevOps Center (declarative UI on top of Git)

• It’s a free Salesforce tool that gives a point-and-click pipeline. It’s built on the same foundation as the Salesforce CLI, and each project is tied to a GitHub repository.   Refer this: devops-center-for-hybrid-teams
• Work items are the main object for defining and tracking changes through their lifecycle. A work item is promoted from one stage to the next in the pipeline, for example Development, QA, UAT, and Production. 
• Instead of rebuilding a component list per hop, you create the list once and the work item carries it through the pipeline. 
• Combining work items merges their feature branches into one branch, which helps with conflicts and dependencies. Because it sits on GitHub, you can also use native GitHub capabilities such as GitHub Actions. 
• It works for hybrid teams: admins stay in the UI while developers keep using VS Code, the CLI, and pull requests. Deployments can be done from DevOps Center or externally with the CLI plugin’s sf project deploy pipeline command, which was in beta when that was written, so check its current status. 

Which one should I use?

• Admin-only team, small and infrequent changes → Change Sets (or move to DevOps Center)
• Mixed admin and developer team, wants Git without everyone learning the CLI → DevOps Center
• Developer-led team needing CI/CD, test gating, scratch orgs, unlocked or managed packages → Salesforce CLI + CI/CD
• Large or regulated enterprise needing approvals, rollback and audit → CLI-based CI/CD, or a commercial DevOps tool.