add more areas for docs

Signed-off-by: Hannah Hunter <hannahhunter@microsoft.com>

daprdocs/content/en/concepts/dapr-services/scheduler.md

@@ -0,0 +1,8 @@
+---
+type: docs
+title: "Dapr Distributed Scheduler control plane service overview"
+linkTitle: "Distributed Scheduler"
+description: "Overview of the Dapr distributed scheduler process"
+---
+
+Need.

daprdocs/content/en/concepts/overview.md

@@ -54,6 +54,7 @@ Each of these building block APIs is independent, meaning that you can use any n
 | [**Distributed lock**]({{< ref "distributed-lock-api-overview.md" >}})  | The distributed lock API enables your application to acquire a lock for any resource that gives it exclusive access until either the lock is released by the application, or a lease timeout occurs. 
 | [**Workflows**]({{< ref "workflow-overview.md" >}}) | The workflow API can be combined with other Dapr building blocks to define long running, persistent processes or data flows that span multiple microservices using Dapr workflows or workflow components. 
 | [**Cryptography**]({{< ref "cryptography-overview.md" >}}) | The cryptography API provides an abstraction layer on top of security infrastructure such as key vaults. It contains APIs that allow you to perform cryptographic operations, such as encrypting and decrypting messages, without exposing keys to your applications.
+| [**Distributed Scheduler**]({{< ref "distributed-scheduler-overview.md" >}}) | The distributed scheduler API is a scalable way to schedule and orchestrate jobs across a distributed computing environment at specific times or intervals.
 
 ### Cross-cutting APIs
 

daprdocs/content/en/developing-applications/building-blocks/distributed-scheduler/distributed-scheduler-overview.md

@@ -6,27 +6,7 @@ weight: 1000
 description: "Overview of the distributed scheduler API building block"
 ---
 
-Dapr users have a need for a distributed scheduler. The idea is to have an *orchestrator* for scheduling jobs in the future either at a specific time or a specific interval.
 
-Examples include:
-- Scalable actor reminders
-- Scheduling any Dapr API to run at specific times or intervals. For example sending Pub/Sub messages, calling service invocations, input bindings, saving state to a state store. 
-
-Implement a change into `dapr/dapr` that facilitates a seamless experience allowing for the scheduling of jobs across API building blocks using a new scheduler API building block and control plane service. The Scheduler Building Block is a job orchestrator, not executor. The design guarantees *at least once* job execution with a bias towards durability and horizontal scaling over precision. This means we **can** guarantee that a job will never be invoked *before* the schedule is due, but we **cannot** guarantee a ceiling time on when the job is invoked *after* the due time is reached.
-
-The **Workflows** building block is built on top of Actor Reminders, which have scale limitation issues today. The goal is to improve the performance and scale of Actor Reminder by using the distributed scheduler.
-
-Currently, Dapr users are able to use the **Publish and Subscribe** building block, but are unable to have delayed PubSub scheduling. This scheduler  service enables users to publish a message in a future specific time , for example a week from today or a specific UTC date/time.
-
-For **Service Invocation**, this building block could also benefit from a scheduler in that it would enable the scheduling of method calls between applications.
-
-As of now, Dapr does have an **input cron binding** component, which can allow users to schedule tasks. This requires the component yaml file, where users can listen on an endpoint that is scheduled. This is limited to being an input binding only. The Scheduler Service will enable the scheduling of jobs to scale across multiple replicas, while guaranteeing that a job will only be triggered by 1 Scheduler Service instance.
-
-*Note:* Performance is the primary focus while implementing this feature given the current shortfalls.
-
-If a user would like to store their user associated data in a specific state store of their choosing, then they can provision a state store using the Dapr State Management Building Block and set `jobStateStore ` as `true` in the state store component’s metadata section. Having the `jobStateStore` set to `true` means that their user associate data will be stored in the state store of their choosing, but their job details will still be stored in the embedded etcd. If the `jobStateStore` is not configured, then the embedded etcd will be used to store both the job details and the user associated data.
-
-*Note:* The Scheduler functionality is usable by both Standalone (Self-Hosted) and Kubernetes modes.
 
 <!-- 
 Include a diagram or image, if possible.