A Salesforce implementation that includes Agentforce changes the technical design before anyone creates the first agent. The team has to decide which records an agent can read, which actions it can execute, which APIs it may call, how Data 360 will supply grounding context, where human approval stays in the path, and how a non-deterministic response will be tested before production. A Flow that updates an opportunity is already an automation decision. Giving an AI agent permission to decide when that Flow should run adds another control layer around intent, data, identity, action selection, exception handling, and monitoring.
That is why the Day One question should be answered during architecture and scope design. An Agentforce Implementation can sit inside the original Salesforce program, but the production agent should enter the first release only when its dependencies are stable enough to test. If account identity is still changing, integration contracts are still being negotiated, permission sets are temporary, knowledge content has no owner, or the business process is still being redesigned, the agent inherits those unsettled decisions. The implementation then has two moving targets at once: the CRM process and the autonomous layer acting on it.
There is a middle path that works for many programs. Agentforce can shape the original architecture, data model, security model, integration plan, test strategy, and release plan while the first production agent waits for a later wave. This keeps the Salesforce Agentforce Implementation connected to the core platform. The activation date should follow technical readiness and business consequences.
TL;DR
- Put Agentforce in the architecture conversation from Day One. Define data sources, permissions, action boundaries, integrations, testing, monitoring, ownership, and expected use cases while the core Salesforce design is still being shaped.
- Put a production agent in the first release only when the use case is bounded. The agent should have a clear trigger, approved data, a small action set, known failure paths, human escalation, and a measurable acceptance condition.
- Use Data 360 deliberately. Enabling Data 360 supports the Agentforce platform foundation. A fuller Data 360 implementation becomes important when the agent needs unified customer data, transformed records, real-time context, zero-copy sources, or advanced retrieval.
- Treat write actions as a higher-risk class than read or draft work. Summaries, retrieval, classification, and draft responses are easier first-wave candidates than refunds, pricing changes, entitlement decisions, account ownership changes, or cross-system transactions.
- Build agent testing beside CRM testing. UAT for screens and Flows cannot prove that an agent will classify intent correctly, choose the right action, handle ambiguous language, or stop when required.
- Delay activation when the foundation is still moving. You can prepare Agentforce Architecture, data, APIs, access, and evaluation assets during implementation, then activate the agent when the business process is stable enough to own its behavior.
Day One Belongs in the Architecture Conversation
The strongest reason to discuss Agentforce during the initial Salesforce implementation is dependency control. Agentforce touches pieces that the implementation team is already designing: object relationships, Flow behavior, Apex logic, API contracts, knowledge, identity, permission sets, data quality rules, and release management. If the program ignores the AI roadmap until after go-live, teams can discover that the new data model lacks the right context, an integration lacks a safe write path, permission sets are too broad, or the knowledge model cannot support grounded responses. Those discoveries push the agent project back into the foundation that was just completed.
The opposite problem appears when the team treats Agentforce as a mandatory Day One feature. That can force decisions before the process is stable. Changing case routing weakens service-agent testing. Disputed opportunity stages make autonomous updates risky. Unowned knowledge creates uncertain grounding. The Salesforce implementation can prepare these surfaces early while production activation follows evidence.
McKinsey’s 2025 State of AI survey captures that wider maturity gap. Sixty-two percent of respondents said their organizations were at least experimenting with AI agents, while nearly two-thirds had yet to start scaling AI across the enterprise. The survey covers enterprise AI broadly rather than Agentforce. Its relevance here is sequencing: interest in agents is already common, while repeatable operating control still lags at many organizations.
Use a Readiness Gate Before Agentforce Enters the Release Plan
A planning meeting needs a clearer answer than “we want AI in phase one.” Use a readiness gate that separates architecture inclusion from production activation.
| Decision state | What must already be true | What the implementation should do | Main warning sign |
| Day One production agent | Use case is narrow, data is trustworthy, action permissions are defined, integrations are testable, and an owner accepts the outcome | Build, test, deploy, monitor, and train users around the agent in the first release | The agent depends on requirements that are still changing weekly |
| Architect now, activate later | AI use case is clear enough to shape data, security, APIs, knowledge, and testing, but one or more dependencies are unfinished | Design Agentforce Data Readiness, access, action contracts, evaluation cases, and release hooks during the main implementation | The team postpones every AI dependency and assumes it can be bolted on after go-live |
| Later roadmap item | Business value is unclear, process ownership is weak, data sources are unknown, or autonomy has no accepted boundary | Keep the core implementation clean and document the open questions that would trigger a future Agentforce Implementation Strategy | The project creates speculative objects, APIs, or custom logic for an agent nobody can define |
The middle state deserves more attention because it solves a common planning conflict. Architecture can account for Agentforce without making the first go-live carry the entire Agentforce Adoption burden. The team can create clean integration contracts, preserve useful data fields, keep action logic reusable, plan narrow permission sets, and capture evaluation cases as the CRM process takes shape. When the dependency gate passes, activation becomes a controlled release instead of a second discovery project.
If the business is still deciding between user-assisted AI and autonomous execution, Agentforce vs. Einstein Copilot comparison is a useful internal reference. The autonomy decision matters because it changes what the implementation team must prove. A user who reviews a draft before acting carries a different risk boundary from an agent that can select and execute an action on its own.
When Agentforce Earns a Place in the Initial Scope
The use case has a hard boundary
A first-wave agent should have a job that can be explained without a long exception tree. “Answer approved policy questions and escalate when confidence or eligibility is unclear” is testable. “Handle customer service” is too broad. “Prepare an account briefing from approved CRM and order data” has a defined information surface. “Help sales” leaves too much interpretation inside the agent.
The boundary should include entry conditions, allowed subagents, allowed actions, prohibited actions, escalation triggers, and the record or event that proves completion. This gives the team a real acceptance model. It also prevents scope growth from hiding inside natural-language instructions, where one added sentence can quietly expand the behavior of the agent.
The data required for the decision already has an owner
Agentforce Data Readiness starts with source records and ownership. The implementation team should know which system owns customer identity, order status, product entitlement, contract terms, case history, consent, pricing, and any other field that changes what the agent may say or do. If two systems can disagree, the agent needs a rule for which source wins or a rule that forces escalation.
Data 360 can strengthen this foundation when the use case needs harmonized records, identity resolution, transformed information, real-time context, or retrieval across structured and unstructured sources. The project still needs to define the business meaning of that data. A unified profile still leaves policy decisions unresolved, such as whether a stale ERP order blocks a refund or whether a CRM flag has legal authority. Those rules belong to the business and architecture teams.
At HyphenX, our article on Salesforce CRM cleanup before scaling AI is directly relevant here. Duplicate accounts, stale ownership, inconsistent status fields, and missing relationships can look manageable during ordinary reporting. Once an agent uses the same records to choose an action, the cost of a bad field can move from a dashboard issue into a customer or transaction issue.
The team can measure the outcome without reading every transcript
The first production use case needs an operating metric that can be inspected after launch. A service agent might track correct resolution, escalation, abandonment, repeated contact, or handle-time change. A sales agent might track accepted meeting briefs, update accuracy, or qualified handoffs. A knowledge agent might track answer acceptance and correction patterns. The measure should describe task quality rather than raw conversation volume.
Salesforce has reported customer results that show why bounded use cases can justify early deployment. In its Agentforce 3 customer results and announcement, Salesforce said Engine reduced average customer case handle time by 15%, 1-800Accountant autonomously resolved 70% of administrative chat engagements during critical tax weeks in 2025, and Grupo Globo increased subscriber retention by 22%. These are vendor-reported customer outcomes rather than a general performance benchmark. They still show the pattern a Day One candidate should follow: a defined workflow, a measurable result, and an operating team able to inspect what the agent is doing.
Data 360 Changes What "Ready" Means
Salesforce now uses the name Data 360 for the product previously called Data Cloud. For Agentforce, there is an important difference between having Data 360 enabled and having it implemented for the use case. Enablement provides the platform foundation used by Agentforce features. A deeper implementation connects sources, maps data, applies transformations, resolves identities where required, and gives agents access to the enterprise context needed for more demanding grounding patterns.
A Day One agent usually needs the second level only when its decisions depend on data that sits outside the core CRM record or when the context has to be assembled from several sources. A service FAQ agent grounded in a controlled knowledge library has a smaller data problem than an account agent that needs CRM history, subscription state, product usage, billing status, open cases, and contract terms. The implementation team should size the data work to the use case rather than turn every Agentforce project into a full customer-data program.
Before the agent build starts, confirm these data conditions:
- The required objects, fields, knowledge sources, and external records are named.
- The source of truth for each decision-bearing field is explicit.
- Identity matching rules are tested where multiple records represent the same person or account.
- Stale data has a defined tolerance, especially for orders, entitlement, inventory, pricing, or account status.
- Sensitive fields have a clear reason for agent access.
- Retrieval sources have publication, update, and retirement owners.
- The team can reproduce the data used in a failed agent interaction during investigation.
That last point matters during support. If an agent produces the wrong answer and the team cannot reconstruct which record, document, or retrieved passage influenced it, the issue becomes difficult to diagnose. Agentforce Data 360 design should therefore include traceability requirements beside data access requirements.
Agent Actions Inherit Every Weak Contract Around Them
A production agent becomes more demanding when it can call an API or trigger business logic. The action may be implemented correctly and still be unsafe for autonomous use because the surrounding contract was designed for a human-operated application. Humans can pause when a response looks strange, retry after checking a record, or ask another team what a status code means. An agent needs those conditions expressed in machine-readable behavior.
| Action surface | Day One question | Evidence before activation | What failure looks like |
| Salesforce Flow | Can the action run twice without creating a duplicate state? | Replay tests, rollback path, clear fault handling | Duplicate tasks, repeated updates, conflicting automation |
| Apex action | Are validation, limits, exceptions, and business ownership documented? | Unit tests, negative cases, error contract, named owner | Agent retries into the same failure or exposes raw errors |
| External API | Can the agent tell success, rejection, timeout, and partial completion apart? | Typed responses, auth scopes, idempotency, rate limits, monitoring | Duplicate orders, uncertain completion, silent downstream failure |
| Knowledge retrieval | Can the agent distinguish current approved content from stale or conflicting material? | Publication rules, source labels, retrieval tests, fallback behavior | Confident answer grounded in obsolete content |
| Human handoff | Does the receiving team get enough context to continue without restarting the interaction? | Handoff payload, queue ownership, escalation SLA | Customer repeats the issue or work lands without an owner |
This is why the Agentforce Integration conversation has to begin before the agent is connected to external systems. Analysis of why Salesforce integrations fail focuses on source-of-truth rules, mapping, error handling, monitoring, and ownership. Those same weaknesses become harder to tolerate when an AI agent is the caller because the system can invoke the interface repeatedly and at machine speed.
Postman’s 2025 State of the API report surveyed more than 5,700 developers, architects, and executives. It found that 89% of developers use AI, while only 24% actively design APIs with AI agents in mind. Fifty-one percent cited unauthorized or excessive API calls from AI agents as a top security concern. The report is API-industry research rather than Salesforce research, but it maps closely to Agentforce Integration design: predictable schemas, scoped authentication, typed errors, rate controls, and current documentation become part of agent readiness.
Permissions Should be Designed Around the Agent's Job
Agentforce Security and Governance begins with a simple question: what is the smallest set of records and actions this agent needs to complete its approved task? The answer should produce a permission surface narrower than the convenience permissions commonly used during implementation. Temporary admin access, broad integration users, inherited permission-set groups, and shared credentials can all hide during build work because the project team wants speed. They become a production risk when an autonomous process receives the same reach.
The security design should separate four things. First, builder permissions control who can configure agents, instructions, actions, and tests. Second, runtime permissions determine what the agent can read and execute. Third, integration identity controls what connected systems accept from the agent path. Fourth, human escalation permissions determine what the receiving user can see and change after handoff. Mixing these layers makes it harder to explain why an action succeeded or why access was denied.
Guide to Salesforce permission hygiene and least privilege is useful before Agentforce Deployment because permission debt accumulates quietly. For an agent, access review should include objects, fields, records, connected apps, credentials, APIs, external actions, knowledge sources, and any Flow or Apex operation available through its action set.
The Build Needs Two Test Plans
Traditional Salesforce testing proves configured behavior: validation rules fire, Flows follow expected branches, Apex passes unit tests, integrations send the right payload, and users can complete the process. Agent testing has another job. It has to evaluate how the system interprets natural language, selects subagents and actions, uses context, handles ambiguity, responds to missing data, and escalates when the request leaves its permitted scope.
A practical Agentforce Implementation Best Practices test stack can use five layers:
- Action tests: Prove each Flow, Apex action, API, and handoff works correctly without the agent deciding when to use it.
- Single-interaction tests: Give the agent clear requests, ambiguous requests, incomplete requests, prohibited requests, and requests with conflicting context. Confirm classification, response, action choice, and escalation.
- Multi-turn tests: Test corrections, changed intent, follow-up questions, repeated requests, memory boundaries, and conversations where the user supplies new facts halfway through the interaction.
- Batch evaluation: Run a larger test set against expected outcomes so changes in instructions, retrieval, actions, or models can be compared before release.
- Production observation: Track errors, escalations, abandoned sessions, feedback, action success, cost, and recurring failure patterns after launch. A production issue should create a new regression case.
This test model matters because agent behavior remains probabilistic even when the surrounding Salesforce automation is deterministic. Stanford HAI’s 2026 AI Index reports that agent performance on the OSWorld computer-use benchmark rose from 12% to about 66%, while agents still failed roughly 1 in 3 attempts. OSWorld measures computer use rather than Agentforce, so the result cannot predict Salesforce performance. It still supports scenario testing and failure handling beyond a handful of successful demos.
Pick a First-wave Use Case by Consequence and Control
The best Day One candidate usually combines repeatability with a low cost of being wrong. The agent can still create meaningful time savings while the operating team learns how to test instructions, observe sessions, handle escalation, and update controls.
| Candidate use case | Day One fit | Reason | Acceptance evidence |
| Account or case summary from approved data | Strong | Primarily reads and organizes known context | Source coverage, factual accuracy, user acceptance |
| Knowledge answer with human escalation | Strong | Narrow source set and clear fallback path | Answer quality, citation/source trace, escalation accuracy |
| Lead or case classification | Conditional | Useful when categories and routing ownership are stable | Classification accuracy, routing outcome, override rate |
| Draft email or response for human review | Strong | Human remains the release gate | Edit rate, acceptance rate, policy compliance |
| Record update using a narrow approved action | Conditional | Safe when field authority and rollback are clear | Correct field selection, action success, exception handling |
| Refund, discount, entitlement, or contract decision | Weak for most first waves | Financial and policy consequence is higher | Requires mature policy logic, approval boundaries, audit trail |
| Cross-system order or account change | Weak until interfaces are proven | Depends on API state, idempotency, external ownership, recovery | End-to-end transaction proof and reconciliation |
Collection of real-world Agentforce use cases is useful during this screening step because it keeps the discussion tied to actual jobs. A Day One scope should select one or two tasks where the data, action boundary, and outcome can be inspected. Breadth can follow after the operating team has evidence from those first workflows.
Watch for the Implementation Mistakes that Turn AI Scope Into Rework
Agentforce can create a second layer of project debt when teams add it without changing how architecture decisions are recorded. The agent may look fine in a scripted demo while the production path depends on hidden assumptions.
- Prompt-first design: The team writes instructions before it has settled data authority, action behavior, or escalation rules. Prompt wording then carries business logic that belongs in governed process or code.
- One shared action surface: The agent receives access to a broad set of Flows or APIs because creating narrower actions takes more time. Future teams cannot easily explain which operations the agent truly needs.
- Unowned knowledge: Files and articles are added for grounding without publication status, review dates, business owners, or a rule for conflicting sources.
- Happy-path integration tests: The agent can complete a successful transaction, while timeouts, duplicate retries, partial failures, expired credentials, and downstream rejection remain untested.
- UAT that tests conversation tone: Reviewers focus on whether the response sounds good and spend too little time on source accuracy, action selection, field updates, permissions, and escalation.
- Go-live without an evaluation queue: Nobody owns failed sessions, recurring misclassification, poor retrieval, cost anomalies, or new regression cases after launch.
These mistakes are avoidable when the Agentforce Implementation Strategy shares the same architecture discipline as the rest of Salesforce. Instructions, data, actions, access, test evidence, and operating ownership should all have a named place in the delivery package.
Security Risk Rises with Autonomy and Connectivity
The security question changes once an agent can act across systems. A read-only summary agent has one exposure profile. An agent that can call ERP APIs, create payment links, update contracts, or trigger fulfillment has another. The project should increase control in proportion to the consequence of the action, the sensitivity of the data, and the number of systems involved.
This means security review cannot stop at whether the user is authenticated. The team should test prompt injection and hostile instructions where relevant, confirm that retrieved content cannot grant new authority, constrain API scopes, separate credentials by environment, prevent secrets from appearing in prompts or logs, and define rate or volume controls for high-frequency actions. Human approval should stay in any path where the business is unwilling to accept an autonomous error.
IBM’s 2026 Cost of a Data Breach study examined breaches experienced by 602 organizations. IBM reported that more than 20% had a breach targeting AI models or applications; among the common causes were compromised APIs, applications, or plug-ins at 27% and cloud misconfigurations affecting AI workloads at 27%. The study covers enterprise AI security broadly. For Agentforce Security and Governance, it reinforces a practical point: the surrounding identity, API, application, and cloud controls belong inside the agent threat model.
Three Rollout Patterns Work for Different Implementation States
Pattern 1: Agentforce ships with the first Salesforce release
Use this pattern when the CRM process is already understood, the implementation is replacing a known workflow rather than inventing one, and the agent’s job is narrow. A mature service team moving from another CRM may already know its case categories, escalation rules, knowledge ownership, and entitlement logic. The Salesforce build can reproduce that process while an agent handles one bounded task such as approved knowledge responses or case classification.
The project plan should give Agentforce its own architecture review, data-readiness gate, security review, test pack, release criteria, and production owner. Treating it as a few extra stories inside the main backlog makes the work look smaller than it is.
Pattern 2: Architecture includes Agentforce, production activation follows go-live
This is often the safer choice for a net-new operating model. The implementation team designs records, APIs, knowledge, permissions, telemetry, and reusable actions with Salesforce AI Agents in mind. The CRM launches first. Real production behavior then gives the team better evidence about data quality, exception volume, user workarounds, and integration reliability before the agent starts acting on those processes.
This pattern also gives the team time to build evaluation cases from real interactions. A new service process can collect the questions users actually ask. A new sales process can show which opportunity updates are stable and which still need human judgment. Agentforce Deployment then follows observed operating conditions rather than workshop assumptions.
Pattern 3: Keep Agentforce outside the initial program
Use this when the use case is still a slogan, the data foundation is weak, integration ownership is missing, or the organization has no one prepared to own agent behavior after launch. The right output from the Salesforce implementation is a clean platform and a documented AI-readiness backlog. Speculative agent work can consume architecture time and create fields, APIs, or custom actions that never become useful.
A later Agentforce project can start faster when the core implementation has preserved clean data definitions, reusable actions, current API contracts, narrow access, and maintained knowledge. A clean first release can support an agent later without reopening the foundation.
The Operating Model Matters As Much As the Build
Agentforce Adoption changes work for administrators, architects, business owners, support teams, and end users. Someone has to review performance, approve instruction changes, maintain retrieval sources, investigate failed actions, manage permissions, watch consumption, and decide whether new use cases qualify for autonomy. These responsibilities remain after the implementation partner leaves.
A simple ownership model should name:
- A business process owner who defines what the agent is allowed to accomplish.
- A Salesforce owner who manages configuration, actions, release controls, and access.
- A data or knowledge owner who maintains the sources used for grounding.
- An integration owner for each external action path.
- A security owner who approves runtime access and reviews exceptions.
- An operations owner who reviews agent performance, failures, escalations, and cost.
- A change owner who prepares users to work with the agent and explains where human responsibility remains.
Agent workflows in CRM describe the same preparation at workflow level: clean data, clear scope, escalation rules, human review in early deployments, activity logs, Data 360 readiness, permission review, and checks across Flow, Apex, APIs, and integrations. Those responsibilities make Agentforce an operating capability rather than a one-time configuration task.
Microsoft’s 2025 Work Trend Index drew on a global survey, Microsoft 365 telemetry, and LinkedIn data. Microsoft reported that 82% of leaders expected to use digital labor to expand workforce capacity within 12 to 18 months, while 46% said their organizations were already using agents to automate entire workstreams or business processes. The research is broader than Salesforce, but it explains why implementation ownership needs to be assigned early. Agent adoption changes who supervises work, who handles exceptions, and who remains accountable when a digital worker acts.
Make the Day One Decision With Evidence
A Salesforce implementation should account for Agentforce from the start whenever the business expects AI agents to become part of the platform roadmap. That means designing data, identity, integrations, actions, permissions, testing, monitoring, knowledge, and ownership so an agent can be added without reopening the whole architecture. It also means refusing to treat production activation as a checkbox attached to the first release.
The strongest Day One candidate has a stable process, a bounded job, trusted data, a narrow action surface, explicit access, testable failure behavior, human escalation, and a team prepared to operate it after launch. When those conditions exist, Agentforce can ship inside the original implementation and start producing evidence early. When several conditions are still unresolved, the implementation should prepare the foundation and move activation to a later release gate.
That distinction protects the core Salesforce program and the Agentforce program at the same time. The CRM can go live with a maintainable operating model, while Agentforce enters production when the organization can explain what it will read, what it may do, how it can fail, how success will be measured, and who owns the answer when behavior changes. Day One should define those controls. The production date should follow readiness.
Frequently Asked Questions
Should every new Salesforce implementation include Agentforce?
No universal rule fits every implementation. The roadmap should account for Agentforce when AI agents are likely to become part of the operating model, but production scope depends on use-case clarity, data quality, action boundaries, security, integration maturity, testability, and ownership. A clean Salesforce foundation with documented Agentforce Readiness can be the right first release when those dependencies are still developing.
What is the best first Agentforce use case during a Salesforce implementation?
A good first use case has a narrow task, approved data, limited consequences if the agent makes a mistake, a clear escalation path, and a measurable outcome. Account summaries, knowledge answers with escalation, classification, and draft responses often provide cleaner first-wave boundaries than financial approvals, contract changes, or complex cross-system transactions.
Does Agentforce require Data 360?
Salesforce’s current platform model uses Data 360 as part of the Agentforce foundation. The amount of Data 360 implementation depends on the use case. An agent working with a controlled data library has a different requirement from an agent that needs unified customer profiles, transformed data, real-time context, zero-copy access, identity resolution, or advanced retrieval across several systems.
Can Agentforce use existing Salesforce Flows and Apex?
Agent actions can use existing Salesforce automation where the behavior is appropriate for agent execution. The implementation team should review each action for permissions, validation, idempotency, exception handling, rollback, observability, and ownership. Logic that is safe when a trained user triggers it may need tighter controls when an agent can invoke it autonomously.
How should Agentforce be tested before go-live?
Test the underlying actions first, then test single interactions, ambiguous language, prohibited requests, missing data, multi-turn conversations, escalation, and larger batches of expected outcomes. Production monitoring should feed new failures back into regression testing. Agent testing should be part of the release process whenever instructions, data, retrieval, actions, or models change.
When should Agentforce be delayed until after Salesforce go-live?
Delay production activation when core processes are still changing, data ownership is unclear, APIs are unstable, permission sets are temporary, knowledge is ungoverned, or nobody has accepted ongoing agent ownership. The main implementation can still prepare Agentforce Architecture and technical dependencies so the later release begins with a prepared foundation.
What security controls matter most for Agentforce?
Start with least-privilege runtime access, narrow action scopes, separate integration identities, controlled secrets, clear human approval points, environment separation, logging, and a review of external APIs and connected systems. Security should reflect the consequence of each action. Read-only retrieval, CRM updates, financial transactions, and cross-system operations deserve different control levels.
How does Agentforce affect Salesforce integration design?
Agentforce can turn APIs into machine-operated action paths. Integration contracts therefore need clear authentication, typed success and error responses, idempotency, timeouts, retry rules, rate limits, reconciliation, monitoring, and ownership. An agent should be able to distinguish a completed action from an uncertain or partial transaction without guessing.
Who should own Agentforce after implementation?
Ownership is usually shared. A business owner defines approved outcomes, a Salesforce owner manages configuration and releases, data or knowledge owners maintain grounding sources, integration owners manage external actions, security approves access, and an operations owner reviews agent performance and failures. The exact model can vary, but every recurring responsibility needs a named owner.
What should an Agentforce Implementation Strategy document before build starts?
Document the use case, users, trigger, data sources, source-of-truth rules, allowed and prohibited actions, subagents, integrations, runtime permissions, human escalation, test scenarios, acceptance metrics, monitoring, cost ownership, release process, and post-launch responsibilities. The document should make it possible for another qualified team to understand why the agent is safe to operate and what evidence would justify expanding its scope.
