Clarify a few items in the docs (#15628)

docs/3.0/develop/global-concurrency-limits.mdx

@@ -52,13 +52,13 @@ To implement rate limiting, you can configure "slot decay", which determines how
 
 When you set up a concurrency limit with slot decay:
 1. Each time a slot is occupied, it becomes unavailable for other tasks to use.
-2. The slot eventually becomes available again over time, based on the slot decay rate (i.e. `slot_decay_per_second`).
+2. The slot eventually becomes available again over time, based on the slot decay rate (with `slot_decay_per_second`).
 3. This creates a "rate limiting" effect, limiting how often slots can be used.
 
 To configure slot decay, set the `slot_decay_per_second` parameter when creating or updating a concurrency limit. This value determines how quickly slots refresh:
 
-- A higher value (e.g., 5.0) means slots refresh quickly. Tasks can run more frequently, but with short pauses between them.
-- A lower value (e.g., 0.1) means slots refresh slowly. Tasks run less frequently, with longer pauses between them.
+- A higher value (for example, 5.0) means slots refresh quickly. Tasks can run more frequently, but with short pauses between them.
+- A lower value (for example, 0.1) means slots refresh slowly. Tasks run less frequently, with longer pauses between them.
 
 For example:
 
@@ -362,3 +362,14 @@ async def main():
 if __name__ == "__main__":
     asyncio.run(main())
 ```
+
+## Other ways to limit concurrency
+
+In addition to global concurrency limits, Prefect provides several other ways to limit concurrency for fine-grained control. 
+
+Unlike global concurrency limits, which are a more general way to control concurrency for any Python-based operation, the following concurrency limit options are specific to Prefect objects:
+
+- [Work pool flow run concurrency limits](/3.0/deploy/infrastructure-concepts/work-pools#manage-concurrency)
+- [Work queue flow run concurrency limits](/3.0/deploy/infrastructure-concepts/work-pools#queue-concurrency-limits)
+- [Deployment flow run concurrency limits](/3.0/deploy/index#concurrency-limiting)
+- [Task run concurrency limits](/3.0/develop/task-run-limits)

docs/3.0/develop/task-run-limits.mdx

@@ -10,11 +10,9 @@ Task run concurrency limits use [task tags](#tags). You can specify an optional
 task runs in a `Running` state for tasks with a given tag.
 
 <Tip>
-Tag-based task concurrency is different from [Global Concurrency Limits](/3.0/develop/global-concurrency-limits), though they can be used to achieve similar outcomes. Global Concurrency Limits are a more general way to control concurrency for any python-based operation, whereas tag-based concurrency limits are specific to Prefect tasks.
+Tag-based task concurrency is different from [Global concurrency limits](/3.0/develop/global-concurrency-limits), though they can be used to achieve similar outcomes. Global concurrency limits are a more general way to control concurrency for any Python-based operation, whereas tag-based concurrency limits are specific to Prefect tasks.
 </Tip>
 
-
-
 If a task has multiple tags, it will run only if **_all_** tags have available concurrency.
 
 Tags without specified concurrency limits are treated as unlimited. Setting a tag's concurrency limit to 0 causes immediate abortion of any task runs with that tag, rather than delaying them.
@@ -30,7 +28,7 @@ and instructs the client to try entering a `Running` state again in 30 seconds
 ### Configure concurrency limits
 
 <Tip>
-**Flow run concurrency limits are set at a work pool and/or work queue level**
+**Flow run concurrency limits are set at a work pool, work queue, or deployment level**
 
 While task run concurrency limits are configured through tags (as shown below), [flow run concurrency limits](/3.0/develop/global-concurrency-limits) are configured through work pools and/or work queues.
 </Tip>

docs/3.0/develop/task-runners.mdx

@@ -79,6 +79,7 @@ If you don't specify a task runner for a flow and you call a task with `.submit(
 Prefect uses the default `ThreadPoolTaskRunner`.
 </Tip>
 
+The `max_workers` parameter of the `ThreadPoolTaskRunner` controls the number of threads that the task runner will use to execute tasks concurrently.
 
 ## Access results from submitted tasks