Digital Shelf Labels in Retail: Benefits, Use Cases, and Limits by Store Function addresses a practical problem: how to prioritize DSL use cases by store function and operational readiness. The subject is easy to oversimplify because an electronic shelf label is visible, while the pricing data, software, wireless network, fixtures, operating roles, and exception controls behind it are not. A retailer can buy capable labels and still create a weak outcome if the product master is inconsistent, update confirmation is ignored, store ownership is unclear, or the business case counts benefits that were never measured.
The source page, "Digital Shelf Labels: Key Benefits and Uses in Retail," is used as a starting signal for search demand rather than as text to rewrite. This article independently organizes the topic around the reader's decision chain. It states what must be measured, what evidence is credible, which conditions can change the answer, and what output a team should produce before moving forward. Commercial claims are separated from standards, government guidance, retailer announcements, and transparent analytical assumptions.
The scope is deliberate: Benefits, use cases, limits, and sequencing; not a blanket ROI promise. Adjacent topics such as every possible smart-store technology, full implementation manual and marketing-only benefit claims are kept outside the core answer. Readers who need product options can review electronic shelf label solutions; readers who need an adjacent technical or operational topic will find internal links near the relevant section rather than a generic block of links.
Use Digital Shelf Labels in Retail: Benefits, Use Cases, and Limits by Store Function as a working document, not as a substitute for store evidence. Record assumptions, retain test results, and update its model when store format, label quantity, wage rates, software scope, or service terms change. The outputs for this specific reader task-prioritize DSL use cases by store function and operational readiness-are designed so finance, operations, IT, procurement, an
d store teams can review the same evidence without using different definitions.
Map benefits to a named store task
Map benefits to a named store task becomes actionable when the team states the conclusion it is trying to prove: ROI is credible only when each benefit has a baseline, causal mechanism, owner, measurement method, and cash-flow treatment. The reason is straightforward: price-change labor may be directly measurable, while waste, sales, and trust effects require stronger attribution and should not be counted twice. Without that statement, suppliers can answer with attractive specifications that do not resolve the buyer's actual uncertainty. A decision document should therefore begin with the expected store behavior, the evidence required, and the condition that would cause the team to reject or redesign the idea. In this article, the map benefits to a named store task checkpoint is evaluated specifically for digital shelf labels in retail, so the conclusion should not be transferred to a different scope without retesting.
The operating logic is time studies, control periods, explicit cash-flow timing, sensitivity analysis, and benefit realization reviews. Walmart's 2024 rollout announcement supports the operational breadth of a large retailer rollout, although its stated limitation must remain visible in the decision. Use the source to define a credible starting point, then test the translation into the retailer's architecture. The evidence chain should connect source data, transformation rules, transmission, endpoint state, and human response. Missing one link creates a blind spot where a technically successful update can still deliver the wrong information or arrive too late to support the workflow. For map benefits to a named store task, the evidence record should remain traceable to the stated boundary of Digital Shelf Labels in Retail: Benefits, Use Cases, and Limits by Store Function.
The main exceptions are wage rates, change frequency, store format, adoption behavior, recurring software cost, replacements, and whether saved time is actually redeployed. These are not footnotes; they are variables that determine scope, cost, and risk. A design should show which conditions are supported, which require modification, and which are outside the approved use case. When the condition changes, the team should know whether the answer changes because of physics, software, data quality, staffing, policy, or commercial terms. These conditions are recorded for the map benefits to a named store task decision in digital shelf labels in retail, which makes this checkpoint distinct from the other sections of the analysis.
End the analysis with a benefit register with low, base, and high cases. The record should also define battery-health exceptions, the sampling method, and the escalation threshold. Evidence should be collected during normal trading, high-load periods, and at least one controlled failure. That combination shows not only whether the system can work, but whether the organization can detect, diagnose, and recover when it does not. The named deliverable for map benefits to a named store task must therefore be reviewed against the article-specific objective: prioritize DSL use cases by store function and operational readiness.
Pricing and promotion execution
The strongest way to examine pricing and promotion execution is to work backward from a retail consequence. Here, the conclusion is that peak-season value comes from controlled execution under volume, not from increasing the frequency of price changes without governance. The supporting fact is that holiday periods concentrate promotion, assortment movement, temporary labor, and shopper traffic, increasing the consequence of stale or partial updates. This framing prevents a feature checklist from becoming a substitute for analysis. A feature has value only when it changes a named task, reduces a measured risk, improves a controlled information flow, or creates an option the retailer is prepared to operate. In this article, the pricing and promotion execution checkpoint is evaluated specifically for digital shelf labels in retail, so the conclusion should not be transferred to a different scope without retesting.
Execution depends on effective-date cleanup, change windows, approval tiers, load testing, war-room ownership, rollback, and post-season review. FMI's grocery shelf digitization article supports the grocery operating rationale for shelf digitization, although its stated limitation must remain visible in the decision. The source does not remove the need for store evidence. Procurement should request configuration details, test logs, architecture boundaries, support processes, and examples of exception behavior. Operations should then verify those claims with its own data and fixtures. The result is a layered evidence model rather than trust in either a brochure or a single demonstration. For pricing and promotion execution, the evidence record should remain traceable to the stated boundary of Digital Shelf Labels in Retail: Benefits, Use Cases, and Limits by Store Function.
Do not ignore blackout periods, channel synchronization, supplier-funded promotions, temporary fixtures, staffing, and network load. They determine whether the result remains valid outside the demonstration. The analysis should specify a supported range and a review trigger. It should also distinguish recoverable exceptions from conditions that require a different design. A short retry may solve a temporary transmission problem; it will not fix a wrong product mapping or a promotion rule that was approved with the wrong effective date. These conditions are recorded for the pricing and promotion execution decision in digital shelf labels in retail, which makes this checkpoint distinct from the other sections of the analysis.
The section's deliverable is a peak calendar and a contingency matrix with named decision rights. Pair store-level adoption readiness with an error measure, a recovery measure, and a cost measure. A balanced set avoids local optimization. For example, faster updates are not an improvement if they produce more mismatches, create more associate interventions, or require an expensive support model that was excluded from the business case. The named deliverable for pricing and promotion execution must therefore be reviewed against the article-specific objective: prioritize DSL use cases by store function and operational readiness.
Function and use-case matrix
| Decision element | Required input | Evidence or test | Pass condition |
|---|---|---|---|
| Scope | Define the store, department, geography, or revenue layer for digital shelf labels in retail | Approved source list and boundary statement | No material category is silently added or removed |
| Baseline | Record the current time, error, cost, or adoption measure | Timestamped operational sample using a stated denominator | A reviewer can reproduce the baseline |
| System behavior | Specify data, display, network, and user response | Store test under normal and peak conditions | Target result is achieved and failures are visible |
| Lifecycle | Include software, support, spares, fixtures, and replacement work | Contract schedule and seven-year cash-flow model | No major recurring or end-of-life cost is excluded |
| Decision | Name the owner of the function and use-case matrix | Signed decision record with residual risks | Go, revise, or stop is tied to evidence |
The function and use-case matrix is a control surface for digital shelf labels in retail, not proof that the project will succeed. Its value is that it exposes missing inputs and prevents teams from comparing unlike scopes. Change its rows when the article's conditions change, retain the evidence behind each cell, and record why the pass threshold for this specific decision tool was selected.
Order picking and shelf location support
The decision behind Order picking and shelf location support is narrower than the headline suggests. For Retail leaders, merchandising, operations, marketing, and IT teams, the useful question is whether order picking and shelf location support should be converted into a measurable decision for digital shelf labels in retail, not left as a broad aspiration. The article therefore treats the operational value of digital shelf labels in retail depends on data, people, fixtures, network behavior, and lifecycle support working together. That distinction prevents a common failure: purchasing or planning around a capability statement while leaving the operational condition undefined. The working unit should be a store, department, workflow, or forecast assumption that can be observed and changed, not an abstract promise about digital transformation. In this article, the order picking and shelf location support checkpoint is evaluated specifically for digital shelf labels in retail, so the conclusion should not be transferred to a different scope without retesting.
The mechanism is a controlled data path from the authoritative business system to the shelf endpoint. In practice, the team should name the authoritative input, record the event that starts the process, confirm the system response, and define the exception path. NRF's 2026 retail trend analysis supports the wider retail focus on automation and inventory decisions, although its stated limitation must remain visible in the decision. Evidence is strongest when the same definition is used in the baseline, pilot, supplier test, and business case; otherwise each group can report a different version of success. For order picking and shelf location support, the evidence record should remain traceable to the stated boundary of Digital Shelf Labels in Retail: Benefits, Use Cases, and Limits by Store Function.
Conditions can reverse the conclusion. Relevant variables include fixture incompatibility, network dead zones, unclear ownership and overstated savings. A result that works in one store format or one department should not be generalized until these variables are tested. The team should also separate a technical limit from a policy choice. A system may permit frequent updates, for example, while governance intentionally restricts who can approve them, when they become effective, and how shoppers are protected during partial failure. These conditions are recorded for the order picking and shelf location support decision in digital shelf labels in retail, which makes this checkpoint distinct from the other sections of the analysis.
The practical output is a written pass/fail criterion. It should include an owner, evidence source, threshold, review date, and residual risk. One useful metric is update success rate, but it needs a denominator and a time window. A rate without the number of attempted updates, affected labels, or trading hours can hide the operational consequence. The output becomes decision-ready only when a reviewer can reproduce the calculation and trace the result to store evidence. The named deliverable for order picking and shelf location support must therefore be reviewed against the article-specific objective: prioritize DSL use cases by store function and operational readiness.
A final control for this part of the decision is to connect the evidence to the next operating document. The related order picking and shelf location support resource can hold the adjacent depth, while the current article retains the boundary defined above. This prevents duplicate explanations and gives the owner a clear place to maintain specifications, calculations, or troubleshooting steps as the system changes.
Inventory visibility and replenishment cues
Retail teams often begin inventory visibility and replenishment cues with a product discussion. A better starting point is the business decision: inventory visibility and replenishment cues should be converted into a measurable decision for digital shelf labels in retail, not left as a broad aspiration. That reframing matters because the operational value of digital shelf labels in retail depends on data, people, fixtures, network behavior, and lifecycle support working together. It also keeps the scope aligned with the article's boundary. The goal is not to describe every possible feature; it is to identify the few inputs that determine whether the intended retail outcome is plausible, measurable, and supportable over the system life. In this article, the inventory visibility and replenishment cues checkpoint is evaluated specifically for digital shelf labels in retail, so the conclusion should not be transferred to a different scope without retesting.
A sound design uses a measured baseline followed by a limited change and an explicit acceptance threshold. The sequence should be visible in a process map, not buried in vendor configuration. GS1's retail 2D implementation guidance supports the link between data, automation, recalls, and stock processes, although its stated limitation must remain visible in the decision. The source establishes a useful boundary, but the retailer still has to translate it into local requirements, data fields, operating roles, test cases, and escalation rules. This translation step is where a general technology claim becomes a store control. For inventory visibility and replenishment cues, the evidence record should remain traceable to the stated boundary of Digital Shelf Labels in Retail: Benefits, Use Cases, and Limits by Store Function.
Several conditions deserve explicit treatment: network dead zones, unclear ownership, overstated savings and inconsistent effective times. Each should be written as an assumption that can be verified. If an assumption is unknown, the pilot must expose it rather than quietly replacing it with a favorable estimate. Teams should also identify who bears the consequence of failure: a shopper, an associate, the pricing desk, IT support, or a supplier. Consequence determines the necessary control strength. These conditions are recorded for the inventory visibility and replenishment cues decision in digital shelf labels in retail, which makes this checkpoint distinct from the other sections of the analysis.
The section should leave the reader with a named owner and escalation path. Track price mismatch incidents alongside one quality measure and one recovery measure. This prevents an efficiency metric from rewarding speed while hiding errors or rework. A useful review asks what changed, what did not change, whether the result persisted outside the test window, and whether the operating team can sustain it without project specialists. The named deliverable for inventory visibility and replenishment cues must therefore be reviewed against the article-specific objective: prioritize DSL use cases by store function and operational readiness.
Value dependency chain
- The scope and excluded adjacent topics are written down.
- The source of product, price, promotion, and location data is named.
- The success metric includes a denominator, sampling method, and time window.
- Store fixtures, temperature, lighting, and radio conditions are represented.
- Failed or delayed updates create an observable exception.
- Security, support, software, spares, and end-of-life work are included.
- A named person can approve, pause, roll back, and close the decision.
- Claims presented to executives or shoppers remain within the evidence.
For the value dependency chain in this digital shelf labels in retail decision, a checked box means the evidence exists and has been reviewed; it does not mean the item was merely discussed. Attach the relevant report, contract clause, screenshot, data extract, or signed test result. Items that cannot be evidenced belong in this article's risk register or the next pilot cycle.
Shopper information and assisted selling
Shopper information and assisted selling becomes actionable when the team states the conclusion it is trying to prove: shopper trust depends on consistent prices, understandable information, visible remedies, and disciplined policy rather than on the display medium alone. The reason is straightforward: industry and retailer sources describe accuracy and information benefits, while consumer concern often focuses on how quickly retailers could change prices. Without that statement, suppliers can answer with attractive specifications that do not resolve the buyer's actual uncertainty. A decision document should therefore begin with the expected store behavior, the evidence required, and the condition that would cause the team to reject or redesign the idea. In this article, the shopper information and assisted selling checkpoint is evaluated specifically for digital shelf labels in retail, so the conclusion should not be transferred to a different scope without retesting.
The operating logic is one authoritative price, effective-time controls, endpoint confirmation, exception handling, audit logs, and plain-language communication. FMI's grocery shelf digitization article supports the grocery operating rationale for shelf digitization, although its stated limitation must remain visible in the decision. Use the source to define a credible starting point, then test the translation into the retailer's architecture. The evidence chain should connect source data, transformation rules, transmission, endpoint state, and human response. Missing one link creates a blind spot where a technically successful update can still deliver the wrong information or arrive too late to support the workflow. For shopper information and assisted selling, the evidence record should remain traceable to the stated boundary of Digital Shelf Labels in Retail: Benefits, Use Cases, and Limits by Store Function.
The main exceptions are unit pricing, promotions, loyalty prices, local rules, accessibility, app synchronization, and partial system outages. These are not footnotes; they are variables that determine scope, cost, and risk. A design should show which conditions are supported, which require modification, and which are outside the approved use case. When the condition changes, the team should know whether the answer changes because of physics, software, data quality, staffing, policy, or commercial terms. These conditions are recorded for the shopper information and assisted selling decision in digital shelf labels in retail, which makes this checkpoint distinct from the other sections of the analysis.
End the analysis with a trust control loop and a shopper-facing exception response. The record should also define labor minutes per change batch, the sampling method, and the escalation threshold. Evidence should be collected during normal trading, high-load periods, and at least one controlled failure. That combination shows not only whether the system can work, but whether the organization can detect, diagnose, and recover when it does not. The named deliverable for shopper information and assisted selling must therefore be reviewed against the article-specific objective: prioritize DSL use cases by store function and operational readiness.
Retail media and promotional compliance
The strongest way to examine retail media and promotional compliance is to work backward from a retail consequence. Here, the conclusion is that peak-season value comes from controlled execution under volume, not from increasing the frequency of price changes without governance. The supporting fact is that holiday periods concentrate promotion, assortment movement, temporary labor, and shopper traffic, increasing the consequence of stale or partial updates. This framing prevents a feature checklist from becoming a substitute for analysis. A feature has value only when it changes a named task, reduces a measured risk, improves a controlled information flow, or creates an option the retailer is prepared to operate. In this article, the retail media and promotional compliance checkpoint is evaluated specifically for digital shelf labels in retail, so the conclusion should not be transferred to a different scope without retesting.
Execution depends on effective-date cleanup, change windows, approval tiers, load testing, war-room ownership, rollback, and post-season review. FMI's grocery shelf digitization article supports the grocery operating rationale for shelf digitization, although its stated limitation must remain visible in the decision. The source does not remove the need for store evidence. Procurement should request configuration details, test logs, architecture boundaries, support processes, and examples of exception behavior. Operations should then verify those claims with its own data and fixtures. The result is a layered evidence model rather than trust in either a brochure or a single demonstration. For retail media and promotional compliance, the evidence record should remain traceable to the stated boundary of Digital Shelf Labels in Retail: Benefits, Use Cases, and Limits by Store Function.
Do not ignore blackout periods, channel synchronization, supplier-funded promotions, temporary fixtures, staffing, and network load. They determine whether the result remains valid outside the demonstration. The analysis should specify a supported range and a review trigger. It should also distinguish recoverable exceptions from conditions that require a different design. A short retry may solve a temporary transmission problem; it will not fix a wrong product mapping or a promotion rule that was approved with the wrong effective date. These conditions are recorded for the retail media and promotional compliance decision in digital shelf labels in retail, which makes this checkpoint distinct from the other sections of the analysis.
The section's deliverable is a peak calendar and a contingency matrix with named decision rights. Pair offline-label count with an error measure, a recovery measure, and a cost measure. A balanced set avoids local optimization. For example, faster updates are not an improvement if they produce more mismatches, create more associate interventions, or require an expensive support model that was excluded from the business case. The named deliverable for retail media and promotional compliance must therefore be reviewed against the article-specific objective: prioritize DSL use cases by store function and operational readiness.
A final control for this part of the decision is to connect the evidence to the next operating document. The related retail media and promotional compliance resource can hold the adjacent depth, while the current article retains the boundary defined above. This prevents duplicate explanations and gives the owner a clear place to maintain specifications, calculations, or troubleshooting steps as the system changes.
Anti-use-case table
| Decision element | Required input | Evidence or test | Pass condition |
|---|---|---|---|
| Scope | Define the store, department, geography, or revenue layer for digital shelf labels in retail | Approved source list and boundary statement | No material category is silently added or removed |
| Baseline | Record the current time, error, cost, or adoption measure | Timestamped operational sample using a stated denominator | A reviewer can reproduce the baseline |
| System behavior | Specify data, display, network, and user response | Store test under normal and peak conditions | Target result is achieved and failures are visible |
| Lifecycle | Include software, support, spares, fixtures, and replacement work | Contract schedule and seven-year cash-flow model | No major recurring or end-of-life cost is excluded |
| Decision | Name the owner of the anti-use-case table | Signed decision record with residual risks | Go, revise, or stop is tied to evidence |
The anti-use-case table is a control surface for digital shelf labels in retail, not proof that the project will succeed. Its value is that it exposes missing inputs and prevents teams from comparing unlike scopes. Change its rows when the article's conditions change, retain the evidence behind each cell, and record why the pass threshold for this specific decision tool was selected.
Limits created by data and operating maturity
The decision behind Limits created by data and operating maturity is narrower than the headline suggests. For Retail leaders, merchandising, operations, marketing, and IT teams, the useful question is whether the shelf display is the final endpoint of a data and control system; failures upstream can be rendered perfectly and still be wrong. The article therefore treats GS1 standards can support consistent identification, while ESL platforms still require correct retailer master data, binding, effective times, and confirmations. That distinction prevents a common failure: purchasing or planning around a capability statement while leaving the operational condition undefined. The working unit should be a store, department, workflow, or forecast assumption that can be observed and changed, not an abstract promise about digital transformation. In this article, the limits created by data and operating maturity checkpoint is evaluated specifically for digital shelf labels in retail, so the conclusion should not be transferred to a different scope without retesting.
The mechanism is defining a source of truth, data contract, identifier mapping, render rules, delivery acknowledgment, audit log, and exception ownership. In practice, the team should name the authoritative input, record the event that starts the process, confirm the system response, and define the exception path. GS1's retail 2D implementation guidance supports the link between data, automation, recalls, and stock processes, although its stated limitation must remain visible in the decision. Evidence is strongest when the same definition is used in the baseline, pilot, supplier test, and business case; otherwise each group can report a different version of success. For limits created by data and operating maturity, the evidence record should remain traceable to the stated boundary of Digital Shelf Labels in Retail: Benefits, Use Cases, and Limits by Store Function.
Conditions can reverse the conclusion. Relevant variables include multiple POS systems, duplicate SKUs, variable-measure goods, planogram moves, promotions, store-specific prices, and offline operation. A result that works in one store format or one department should not be generalized until these variables are tested. The team should also separate a technical limit from a policy choice. A system may permit frequent updates, for example, while governance intentionally restricts who can approve them, when they become effective, and how shoppers are protected during partial failure. These conditions are recorded for the limits created by data and operating maturity decision in digital shelf labels in retail, which makes this checkpoint distinct from the other sections of the analysis.
The practical output is an end-to-end data flow and a responsibility map. It should include an owner, evidence source, threshold, review date, and residual risk. One useful metric is time to resolve exceptions, but it needs a denominator and a time window. A rate without the number of attempted updates, affected labels, or trading hours can hide the operational consequence. The output becomes decision-ready only when a reviewer can reproduce the calculation and trace the result to store evidence. The named deliverable for limits created by data and operating maturity must therefore be reviewed against the article-specific objective: prioritize DSL use cases by store function and operational readiness.
Sequence use cases from reliable to experimental
Retail teams often begin sequence use cases from reliable to experimental with a product discussion. A better starting point is the business decision: sequence use cases from reliable to experimental should be converted into a measurable decision for digital shelf labels in retail, not left as a broad aspiration. That reframing matters because the operational value of digital shelf labels in retail depends on data, people, fixtures, network behavior, and lifecycle support working together. It also keeps the scope aligned with the article's boundary. The goal is not to describe every possible feature; it is to identify the few inputs that determine whether the intended retail outcome is plausible, measurable, and supportable over the system life. In this article, the sequence use cases from reliable to experimental checkpoint is evaluated specifically for digital shelf labels in retail, so the conclusion should not be transferred to a different scope without retesting.
A sound design uses lifecycle planning that includes software, support, spares, batteries, fixtures, and replacement labor. The sequence should be visible in a process map, not buried in vendor configuration. Walmart's 2024 rollout announcement supports the operational breadth of a large retailer rollout, although its stated limitation must remain visible in the decision. The source establishes a useful boundary, but the retailer still has to translate it into local requirements, data fields, operating roles, test cases, and escalation rules. This translation step is where a general technology claim becomes a store control. For sequence use cases from reliable to experimental, the evidence record should remain traceable to the stated boundary of Digital Shelf Labels in Retail: Benefits, Use Cases, and Limits by Store Function.
Several conditions deserve explicit treatment: support obligations that end too early, unclean master data, unconfirmed updates and fixture incompatibility. Each should be written as an assumption that can be verified. If an assumption is unknown, the pilot must expose it rather than quietly replacing it with a favorable estimate. Teams should also identify who bears the consequence of failure: a shopper, an associate, the pricing desk, IT support, or a supplier. Consequence determines the necessary control strength. These conditions are recorded for the sequence use cases from reliable to experimental decision in digital shelf labels in retail, which makes this checkpoint distinct from the other sections of the analysis.
The section should leave the reader with a documented residual-risk register. Track promotion execution accuracy alongside one quality measure and one recovery measure. This prevents an efficiency metric from rewarding speed while hiding errors or rework. A useful review asks what changed, what did not change, whether the result persisted outside the test window, and whether the operating team can sustain it without project specialists. The named deliverable for sequence use cases from reliable to experimental must therefore be reviewed against the article-specific objective: prioritize DSL use cases by store function and operational readiness.
Portfolio sequence plan
- Define the exact decision and boundary for digital shelf labels in retail.
- Capture the current-state baseline with a denominator and time window.
- Prepare source data, roles, test fixtures, and escalation paths.
- Run the change in a representative store or controlled scenario.
- Confirm endpoint results and route every exception to an owner.
- Compare the result with pass thresholds and lifecycle economics.
- Record a go, revise, or stop decision and schedule the next review.
The portfolio sequence plan sequence for digital shelf labels in retail is intentionally evidence-led. Skipping its baseline makes benefit claims unverifiable; skipping endpoint confirmation hides partial failure; skipping the decision record allows activity to drift into rollout without approval. Add local controls where price law, pharmacy procedure, cybersecurity, or store trading risk requires them.
Decision-ready next step
The central judgment in Digital Shelf Labels in Retail: Benefits, Use Cases, and Limits by Store Function is not whether electronic labels are modern or popular. It is whether the proposed system can produce the article-specific outcome-prioritize DSL use cases by store function and operational readiness-under the store's real data, fixture, network, staffing, policy, and lifecycle conditions. The strongest decision starts with a bounded task, converts claims into tests, separates direct savings from uncertain benefits, and records the exceptions that could reverse the conclusion.
For Digital Shelf Labels in Retail: Benefits, Use Cases, and Limits by Store Function, build the next action around one named artifact from this article: Function and use-case matrix, Value dependency chain, Anti-use-case table, or Portfolio sequence plan. Assign an owner and a review date. For adjacent depth, use the related electronic shelf label resource rather than expanding the current scope until it loses its decision focus. A supplier conversation is productive when both sides can point to the same requirements, evidence, and pass conditions.
