Tareas recurrentes en Notion sin automatizaciones externas: Un sistema de gestión de renovaciones de dominios

Supongo que cuando publique este artículo estaremos a punto de terminar el 2022 o comenzando ya el 2023, así que me permitirás que te desee larga vida y prosperidad 🖖 antes de entrar en materia.

Confieso que he reescrito como diez veces el título de esta entrada porque no me gustaba ninguno, tampoco el que se ha quedado finalmente (maldita sea, debería haberle preguntado a ChatGPT), así que mejor te explico de qué va esto con un cuerpo de texto más reducido.

Igual ya sabes que uso mucho Notion. También para llevar la cuenta de los distintos dominios y servicios de alojamiento que tengo contratados.

Lo bueno de dominios y hospedajes es que te permiten construir tu identidad digital. Lo malo, que hay que renovarlos, si eres un poco conservador como yo, anualmente. Y acordarse de hacerlo antes de los plazos establecidos para que no pasen cosas desagradables, por ejemplo, que pierdas tu dominio gratuito TK sin posibilidad de recuperación a menos que pases por caja, que siempre duele 🙋‍♂️.

☝ Cualquier persona práctica y razonable simplemente anota estas cosas en alguna herramienta de gestión de eventos o tareas capaz de recordarnos todos esos plazos letales con la debida antelación. Y que además lo haga año tras año, puntualmente, para que nosotros solo tengamos que estar pendientes de hacer clic en su momento (y abrir la cartera).

Hay miles de ellas: Google Calendar, Todoist, Asana... Si es que hasta Google Tasks, que es más simple que el mecanismo de un botijo, nos permite definir tareas que se repiten con distintas periodicidades y emite las oportunas notificaciones de aviso (aunque ojito con su antelación).

Pero he aquí que, volviendo a mis manías, a mi me gusta meter todas mis cositas en Notion. Llámame cuadriculado (con razón). Y lo de las tareas periódicas en Notion, como que no. Mucha navaja suiza de la productividad, pero Todoist y Asana se encanan cuando les hablas del /remind de Notion.

Pero no pienses que esto es cosa solo de Notion. A otras herramientas de vocación similar, por ejemplo Coda, tampoco parece importarles mucho eso de las tareas recurrentes y sus correspondientes notificaciones. Verdad de la buena, el lenguaje de fórmulas de Coda (asquerosamente potente 😍), arropado por sus automatizaciones internas, permite hincarle el diente al problema y resolverlo dignamente de mil maneras distintas, aunque  personalmente no deja de sorprenderme la ausencia de cierto soporte nativo para algo tan habitual como es la gestión de tareas. Tal vez poerque es algo que les queda pequeño a las navajas suizas.

Más sobre tareas periódicas, Notion y especialmente Coda, aquí:

Pero centrémonos en Notion, donde, afortunadamente, las cosas por lo que hace al problema que nos ocupa han cambiado para mejor hace nada.

El 8 de noviembre pasado Notion lanzaba una nueva función que se anunció en su momento como la solución para el problema del que te hablaba en los párrafos anteriores

Básicamente, la idea es que ahora cualquier plantilla asociada a una base de datos puede engendrar automáticamente una página nueva dentro de ella siguiendo una regla de recurrencia, definida mediante una serie de ajustes específicos e independientes para cada plantilla, que determina su periodicidad.

¿Pone esto por fin a Notion a la altura de los pesos pesados de la gestión de tareas? Pues, en mi opinión... ¡ni de coña!

Pero como dicen los creadores de contenido de pro, toxicidad fuera, mala vibra fuera. La verdad sea dicha, esta nueva característica ciertamente desbloquea nuevos escenarios de uso de Notion que mejoran notablemente la situación. Y de eso va este artículo.

👇 ¡En resumen! 👇
En este artículo te cuento cómo usar las nuevas plantillas con repetición de Notion para construir un sistema que emite notificaciones periódicas asociadas a una serie de eventos o tareas y te facilito una plantilla de gestión de renovaciones de dominios y servicios de alojamiento basada en la estrategia descrita.

Tareas recurrentes (o algo así) en Notion

Vamos primero que nada a dejar claro qué pretendemos conseguir, que no hay nada peor que resolver correctamente el problema equivocado.

Por un lado, utilizo una base de datos de Notion monda y lironda para almacenar una lista de dominios y servicios de alojamiento que deben ser renovados, pongamos que anualmente. Vamos a llamarles a partir de ahora simplemente suscripciones.

Cada una de estas suscripciones está caracterizada por cierta información. Ahora solo nos interesa un detalle: la fecha de vencimiento de cada contrato de suscripción, esto es, el día concreto en que este expirará y dejará de tener validez, si no se ha renovado antes.

Para evitar tragedias, vamos a dejar las las cosas claras. Pongamos que el 22/08/22 he contratado el dominio pablofelip.online por un año. Esto quiere decir que el 22/08/23 a las 00:00 horas dejará de funcionar. Esta es por tanto su fecha de vencimiento y deberé renovarlo, como tarde, en algún momento del día anterior, el 21 de agosto.

Bien, tenemos dos problemas a resolver, así que necesitaremos otras tantas soluciones:

Hagamos una prueba para ver si esto es viable antes de liarnos a montar un tinglado más gordo.

Primero, creamos una plantilla como esta en la base de datos de suscripciones:

A continuación, definimos la repetición.

Fíjate en la variedad de ajustes que se utilizan para determinar cuándo se generará una nueva página en la base de datos a partir de la plantilla:

• Tipo de periodicidad (anual)
• Cadencia (cada año)
• Fecha de inicio (29/12/22)
• Hora (19:14)

Y justo a las 19:14 Notion nos lanzará esta simpática notificación:

🚨 A 12/01/23 existe un error en Notion que afecta al valor de fecha y hora de la próxima repetición (Next:), que se muestra en gris en la parte inferior del cuadro de diálogo de repetición, cuando se escoge una periodicidad mensual o anual. Solo hay que toquetear un poco los controles para que se salte la primera ocurrencia (Starts)... e incluso alguna más si modificas el valor de Every.  

☝ Afortunadamente, parece que solo se trata de un glitch visual. Guarda tus ajustes de repetición, cierra el cuadro de diálogo y vuelve a abrirlo, comprobarás que ya se muestran entonces la fecha y horas correctas. Para tu tranquilidad, asegúrate de realizar esta verificación en tanto este problemilla no esté resuelto.

Además, si no has visto la notificación pasados 5 minutos, deberías recibir también un conveniente aviso push en tu dispositivo móvil, si tienes la app de Notion instalada, naturalmente.

Y si no estamos activos en la app de Notion (ya sea en el navegador, aplicación de escritorio o de móvil o tableta) o hemos activado el ajuste para recibir siempre notificaciones a través del correo electrónico, también recibiremos este otro aviso 📨:

☝ Llegados a este punto, tal vez quieras repasar cómo y cuándo notifica Notion cositas. Consulta para ello raudo y veloz esta página de la ayuda oficial.

Bueno, pues hasta donde llega mi conocimiento, este es el mejor "apaño" que podemos lograr tirando de esta nueva característica de Notion que permite generar copias a cascoporro de una plantilla de una base de datos de manera periódica y totalmente automática.

¿Te convence?

A mí solo por días. Creo que esta función puede venir muy bien en ciertos casos de uso, por ejemplo, a la hora de facilitar el registro de hábitos (los famosos habit trackers que tanto abundan en el ecosistema Notion). O para documentar reuniones y otros eventos que tienen carácter periódico.... Pero elevarla a la categoría de posibilitadora de un sistema de gestión de tareas recurrentes hecho y derecho me parece un pelín optimista, francamente.

Como contaba en un tuit enlazado más arriba, veo más que la recurrencia pudiera definirse a nivel de página (que no de plantilla). Esto, junto con un mecanismo de autoborrado de páginas, abriría nuevas posibilidades que permitirían desplegar tareas recurrentes cuyo comportamiento fuera más natural, desde mi punto de vista.

Pero bueno, los caminos de Notion son inescrutables, así que más vale que pensemos en el modo de sacar el mayor partido posible a lo que tenemos.

Vamos ahora con la plantilla que ha salido de toda esta, vamos a llamarla, prueba de concepto. Igual ya estás intuyendo que este modo tan peculiar de generar páginas de manera recurrente va a complicarnos un poco las cosas a la hora de construir un sistema útil y funcional. No vas equivocado.

La he llamado RenoDom, por aquello de acortar. Soy bastante consciente de lo estúpido que resulta ese nombre, pero es lo que hay 🤷‍♂️.

RenoDom, una plantilla para gestionar las renovaciones de dominios

RenoDom es una plantilla muy sencilla. Casi tanto como 𝔸-𝕔𝕦𝕖𝕣𝕕𝕒. La he montado en un rato mientras exploraba la estrategia de uso de las plantillas recurrentes que te he contado en el apartado anterior, así que seguro que es muy mejorable e incluso puede que contenga algún que otro error. No, no me voy a hacer responsable de que no renueves a tiempo uno de tus dominios por culpa de una notificación que RenoDom no te ha enviado 🙅‍♂️.

Te la facilito primero, por si eso es lo único que en lo que estás interesado, y en el siguiente apartado te explicaré, si quieres, algunas de sus interioridades y decisiones de diseño.

Haz clic en el enlace, luego en el botón Duplicate y obtén tu copia actualizada de RenoDom. Es gratis, sin registros ni historias.

📑 https://bit.ly/renodom

Las instrucciones de uso las encontrarás en la propia plantilla, así que pasemos sin perder tiempo a hablar de...

Las tripas de RenoDom

Estructura de datos

RenoDom podría haberse construido usando una única base de datos. Y esa probablemente hubiera sido la decisión más pragmática.  Al fin y al cabo, tenemos una serie de dominios y servicios con cierta información básica, así que hubiera bastado con algo como esto:

1. Determinar el número y tipo de propiedades que necesitamos en una (única) base de datos para almacenar la información que precisamos gestionar.
2. Crear tantas plantillas de páginas como suscripciones, usando como nombre de cada una de ellas algo como "midominio.es" o "Renovar midominio.es" y rellenar la información pertinente relativa a cada suscripción (tipo, proveedor, coste, etc.).
3. Establecer la repetición de cada una de esas plantillas de modo que se genere una nueva página unos días antes de que toque renovar la suscripción correspondiente, pongamos 10 o 20, por ejemplo.
4. Añadir una propiedad del tipo 🕘 Created time para registrar la fecha y hora en la que se ha generado cada copia de la plantilla, por aquello de mantener un histórico ordenado (aunque realmente no haría mucha falta).
5. Añadir una propiedad de tipo ☑️ Checkbox para marcar las renovaciones cuando ya se hayan efectuado.
6. Crear un par de vistas de tipo tabla en la base de datos, por ejemplo:
   1. Por renovar: Aplicar en ella un filtro que solo muestre las renovaciones que aún no se han efectuado, ordenadas de manera ascendente por fecha de creación.
   2. Renovadas: Pues eso, otro filtro aquí para visualizar solo las renovaciones ya efectuadas, ordenadas esta vez de manera descendente por fecha de creación y, tal vez, agrupadas por la propiedad principal (de tipo Title) de la página.

Y con eso ya estaría. Simple y un poco cutre, pero probablemente lo suficientemente funcional.

Pero (siempre hay peros) resulta que conceptualmente y desde la perspectiva de la estructura de datos subyacente, aquí estamos más bien manejando dos entidades:

• Suscripciones
• Renovaciones

El diseño inicial funde ambas en una misma colección de objetos, cuando realmente y a poco que te pares a pensarlo, la información que caracteriza a estas entidades es claramente distinta (información del dominio o servicio frente a información específica de un proceso de renovación). No parece demasiado elegante duplicar cosas como el nombre del proveedor o el tipo de suscripción en cada objeto de la base de datos que representa cada una de las renovaciones, salvo cuando la prioridad fuera mantener el sistema lo más simple posible, claro.

Además, las suscripciones perviven, en tanto que las renovaciones viven y mueren con las periodicidades definidas, lo que pone de manifiesto una evidente relación de tipo uno a varios entre ambas entidades, suscripciones y renovaciones, que podemos llevar a Notion en un pispás.

Es por ello que en lugar de la propuesta inicial, basada en una sola tabla, el tinglado se ha diseñado en torno a dos tablas distintas que representan suscripciones y renovaciones, quedando ambas vinculadas mediante una propiedad de tipo ↗️ Relation.

Me pregunto qué sería de la vida sin esos "peros" que nos empujan a hacer las cosas mejor, ¿verdad? 

Empujando datos entre tablas (a vueltas con los rollups)

Notion tiene que hacer algo con sus relaciones y rollups.  Y también con su lenguaje de fórmulas. En serio. Y más pronto que tarde. Hay ya demasiado limitaciones que estorban lo que no está escrito cuando intentas montar algo de cierta complejidad con varias tablas relacionadas.

Entiendo que no solo de power users vive una plataforma. Entiendo que puede resultar complicado encontrar el equilibrio entre añadir funcionalidades cada vez más potentes y sofisticadas, que pueden espantar con su complejidad a esos usuarios que se acercan por primera vez a la herramienta, y tener mediocontentos a los quejicas como yo.

Pero algunos competidores están adelantando a Notion por la derecha, es más, ya le están sacando considerable ventaja en algunos aspectos funcionales que para mí (y me consta que para otros) son muy relevantes.

Aquí solo usaremos dos tablas, pero vamos a tener que empujar información de la una a la otra y de la otra a la una... Y batallar en el proceso contra todas esas limitaciones que mencionaba hace un momento en relaciones, rollups y fórmulas, que se sienten a veces como esos vaqueros que parecen haber encogido tras los interminables atracones navideños. Por ejemplo, estas tres:

• Cuando haces un rollup de tipo  Show original de una propiedad de fecha lo que te llega es texto, aunque solo se devuelva un único valor. Hay que utilizar las funciones  timestamp() y fromTimestamp() para convertir los valores de fecha en numéricos (y viceversa), como si los criogenizáramos para resistir el largo viaje surcando el inconmensurable vacío sideral entre tablas. Un coñazo.
• No hay manera de ajustar el formato con el que se muestran los valores de fecha y hora mediante fórmulas. Vale, sí lo hay, podemos usar formatDate(). Pero lo que sale de ahí ya no es una fecha como dios manda sino texto. Nos quedamos entonces sin las funciones de aritmética de fechas: nada de obtener el número de días entre dos fechas o sumarle años a una dada, al menos sin usar fórmulas de esas que nadie quiere parir.
• Cuando tirando de rollup obtenemos múltiples valores relacionados de la tabla de origen, que llegan separados por comas, nos las tenemos que apañar como podamos para obtener el que nos interese utilizando funciones de manipulación de la cadena de texto obtenida. Sí, eso supone a menudo tener que parir innombrables expresiones regulares que solo deberían aparecer en cuentos de Lovecraft 🐙. ¡Queremos soporte para el manejo de listas en el lenguaje de fórmulas de Notion!

Venga, sin quejas... pero tenía que decirlo. Desde el cariño 💙.

☝ Las tablas que contienen la información de las suscripciones y sus renovaciones asociadas se denominan en RenoDom «Dominios y servicios» y «Avisos dominios y servicios», respectivamente, en lugar de «Suscripciones» y «Renovaciones», términos genéricos utilizados hasta el momento mientras hablábamos de la estructura de datos subyacente.

Voy a intentar resumir en un esquema las propiedades más importantes de RenoDom, así como los flujos de datos que las mueven de un lugar a otro, para que te hagas una idea general de qué está pasando ahí dentro y puedas modificar fácilmente la plantilla para adaptarla a tus necesidades. 

He dejado fuera de este esquema algunas propiedades accesorias. Por ejemplo, unas cuantas utilizadas para mejorar el modo en que se presenta la información en las distintas vistas del sistema.

Algunos aspectos destacables:

1️⃣ Gracias a las plantillas con repetición, se van generando avisos de renovación de manera automática en la tabla «Avisos dominios y servicios». Registraremos la fecha y hora del aviso (que no es otra cosa que una página de la base de datos, no lo olvidemos) gracias a la propiedad «Notificado», de tipo 🕘 Created time.

2️⃣  Las páginas que se crean en la tabla de avisos quedan automáticamente vinculadas con la suscripción que les corresponde gracias a la relación que habremos establecido previamente, por medio del campo «Servicio» (de tipo ↗️ Relation), al crear las plantillas.

3️⃣ En cuanto se genera un nuevo aviso, se determina la próxima fecha de vencimiento de la suscripción asociada. Para ello, primero se obtiene la fecha de alta desde la tabla de dominios gracias al rollup «Alta_Ts», que recupera el valor numérico de la marca de tiempo (timestamp) correspondiente a la fecha de alta registrada en la tabla de dominios. A continuación, se opera con la marca de tiempo y con la fecha de generación del aviso (propiedad «Notificado») para calcular la de vencimiento en la propiedad de tipo fórmula «Vencimiento».

[Vencimiento]
if(month(fromTimestamp(toNumber(prop("Alta_Ts")))) > month(prop("Notificado")) or month(fromTimestamp(toNumber(prop("Alta_Ts")))) == month(prop("Notificado")) and date(fromTimestamp(toNumber(prop("Alta_Ts")))) > date(prop("Notificado")), dateAdd(fromTimestamp(toNumber(prop("Alta_Ts"))), year(prop("Notificado")) - year(fromTimestamp(toNumber(prop("Alta_Ts")))), "years"), dateAdd(fromTimestamp(toNumber(prop("Alta_Ts"))), year(prop("Notificado")) + 1 - year(fromTimestamp(toNumber(prop("Alta_Ts")))), "years"))

Como puedes comprobar si le echas un vistazo a la fórmula anterior, la fecha del próximo vencimiento se calcula utilizando la de creación del aviso (propiedad «Notificado»), en lugar de la actual, y por tanto tendrá un valor constante para cada aviso que se genere. Lo hacemos de este modo porque el sistema necesita "anclar" los distintos vencimientos a sus correspondientes avisos para funcionar correctamente. 

4️⃣ Una vez obtenida la fecha de vencimiento, se actualiza el estado del aviso por medio de dos propiedades,  «Código estado» ([A]tendido / [V]encido / [P]endiente) y «Estado», que utiliza diferentes emojis de colores y descripciones de estado legibles para las vistas a partir de la primera.

[Código estado]
if(prop("Atendido"), "A", if(now() >= prop("Vencimiento"), "V", "P"))

[Estado]
if(prop("Código estado") == "A", "🟩 Renovado", if(prop("Código estado") == "V", "🟥 No renovado", "🟧 En renovación"))

5️⃣ Se utiliza un indicador de progreso de tipo anillo para mostrar visualmente cuántos días faltan para que que la suscripción al dominio o servicio expire (no, ya no me cabía en el diagrama anterior 😅). El rosco se ha configurado de manera que solo comience a vaciarse cuando falten 30 días y calcule la diferencia redondeando siempre a días enteros.

[Días]
if(and(ceil(dateBetween(prop("Vencimiento"), now(), "hours") / 24) >= 0, not prop("Atendido")), ceil(dateBetween(prop("Vencimiento"), now(), "hours") / 24), toNumber(""))

6️⃣ Nos movemos ahora a la tabla «Dominios y servicios». Lo primero que haremos es obtener el número de avisos relacionados de la tabla «Avisos dominios y servicios» mediante el rollup «Nº avisos», que no tiene ningún misterio.

7️⃣ Por su parte, el rollup «Estado avisos» recupera los códigos de estado (propiedad «Código estado») de todos los avisos asociados a una suscripción.  Como solo estamos interesados en el más reciente, la letra que codifica el estado del aviso se extrae a partir del rollup, en la propiedad «Estado ult aviso», mediante una sencilla fórmula, lo que permite reproducir fácilmente también en esta tabla una propiedad análoga a la de «Estado» en la tabla de avisos.  Como además los rollups tienen en cuenta las plantillas de una base de datos que pudieran estar relacionadas (cosas de Notion 🙄), algo que no nos interesa en absoluto en este caso de uso, se realiza una comprobación sobre la cardinalidad del rollup «Nº avisos» para no tenerlas en cuenta como avisos reales.

[Estado ult aviso]
if(prop("Nº avisos") > 1, slice(prop("Estado avisos"), -1), "")

⚠️ Esta movida funciona de rechupete porque los rollups del tipo Show original, de entrada, devuelven la lista de valores de las propiedades de las páginas relacionadas en el orden de la secuencia temporal en la que se establecieron las relaciones, cosa que en RenoDom se produce cuando se genera un aviso a partir de una plantilla como consecuencia de sus ajustes de repetición. Si Notion decidiera en algún momento modificar este comportamiento... pues ya te puedes imaginar (¡buuum!).

8️⃣ Como siempre vamos a querer disponer de la próxima fecha de vencimiento de cada suscripción, con independencia de que se haya generado o no un aviso para ella, en lugar de tratar de utilizar un rollup para recuperarla desde la tabla de avisos realizaremos aquí mismo el cálculo, pero sirviéndonos ahora de la fecha actual. Además, comprobaremos si la fecha de vencimiento asociada al último aviso emitido ha sido superada, en cuyo caso ya no se mostrará la fecha de la siguiente renovación dado que consideraremos el  servicio perdido al no tener constancia de la extensión de su contrato a tiempo.

Prox vencimiento
if(prop("Estado ult aviso") == "V", fromTimestamp(toNumber("")), if(month(prop("Alta")) > month(now()) or month(prop("Alta")) == month(now()) and date(prop("Alta")) > date(now()), dateAdd(prop("Alta"), year(now()) - year(prop("Alta")), "years"), dateAdd(prop("Alta"), year(now()) + 1 - year(prop("Alta")), "years")))

9️⃣ La propiedad «Estado» que encontrarás en esta tabla es un espejo de la que tenemos en la tabla «Avisos dominios y servicios», pero ahora se utiliza para el cálculo la información que hemos obtenido del último aviso generado, ignorando nuevamente la plantilla utilizada para su generación periódica.

[Estado]
if(empty(prop("Estado ult aviso")), "🟦 Sin avisos", if(prop("Estado ult aviso") == "A", "🟩 Renovado", if(prop("Estado ult aviso") == "V", "🟥 No renovado", if(prop("Estado ult aviso") == "P", "🟧 En renovación", ""))))

🔟 Y para terminar, un truqui 🎩🐰 bien vistoso que estoy seguro de que te va a gustar. Mira, mira:

En RenoDom, los anillos de progreso que se muestran en el panel de dominios y servicios serán:

• De color azul 🔵 en tanto el último aviso emitido está marcado como atendido o falten más de 30 días para la fecha de vencimiento de una suscripción.
• De color naranja 🟠 en caso contrario, cuando ya la cosa esté más achuchada.

Pero Notion no permite modificar el color de una barra o anillo de progreso (¡Coda ven a mí!), ¿verdad? En efecto, por esa razón usaremos (primera idea feliz) dos anillos de progreso 😜.

Aquí tienes el primero (🔵):

Días
if(prop("Estado ult aviso") == "A" or ceil(dateBetween(prop("Prox vencimiento"), now(), "hours") / 24) > 30, ceil(dateBetween(prop("Prox vencimiento"), now(), "hours") / 24), toNumber(""))

Y aquí el segundo (🟠):

Días (≤30)
if(prop("Estado ult aviso") == "A" or ceil(dateBetween(prop("Prox vencimiento"), now(), "hours") / 24) > 30, toNumber(""), ceil(dateBetween(prop("Prox vencimiento"), now(), "hours") / 24))

¿Ya lo ves venir?

Usamos sendas funciones if() para determinar, de manera excluyente, cuándo deberá calcularse el valor numérico a representar en cada anillo y cuándo la propiedad deberá devolver un resultado "vacío".

Pero un momento, ¿cómo demonios calcularemos un resultado vacío? Al fin y al cabo, no es lo mismo un cero que ningún resultado. Pues aquí viene la segunda idea feliz, que de hecho ya hemos puesto en práctica, aunque me he hecho el local antes 😏, en la fórmula de la propiedad «Prox vencimiento».

Al usar la función toNumber() con una cadena vacía ("") como parámetro se obtiene la más absoluta y aterradora nada. Es como si a la fórmula le hubiéramos enchufado un agujero negro, de modo que si usamos empty() sobre el resultado obtendremos un rotundo true.

☝ Y esta artimaña no solo funciona con valores numéricos, también la podemos usar con fechas, mira si no este tuit en el que te cuento cómo calcular la fecha del próximo vencimiento de un conjunto de tareas asociadas a un proyecto.

Y ya tan solo resta realizar el truco final. Situaremos las propiedades de tipo fórmula que generan ambos anillos de progreso una junto a la otra y ajustaremos su visibilidad de manera que únicamente se muestren cuando no estén vacías. De este modo solo veremos, tanto en las distintas vistas de la base datos (siempre que no sean de tipo tabla) como en sus propias páginas, un único anillo... que aparentemente cambiará de color dependiendo del nº de días restantes hasta la fecha de vencimiento de cada suscripción.

Y el resto de detalles ya te los dejo para que los investigues tú mismo, si te apetece 🧐...

Comentarios finales y siguientes pasos

Pues así como quien no quiere la cosa, hemos llegado al final.

En este artículo te he explicado cómo sacar partido de las nuevas plantillas con repetición de Notion para construir un sistema de notificaciones periódicas bastante resultón. 

Además, te he presentado una plantilla que se sirve de la estrategia descrita para implementar un sistema de control de las renovaciones de dominios y servicios de alojamiento, que fácilmente podría adaptarse para soportar otros tipos de suscripciones con renovación periódica.

Hemos hablado también de lo humano y lo divino (por lo que hace a Notion), comentando algunas limitaciones de esta herramienta que a mí personalmente me pesan cada vez más.

Al igual que hice en su momento con ps_Clases, te animo a que si estás dando tus primeros pasos con Notion desmenuces RenoDom y la utilices como una herramienta de autoaprendizaje, porque...

Cualquier plantilla Notion que te encuentres por ahí seguramente no será tan buena como tú podrías hacer que llegara a ser.

Y como siempre, aquí abajo 👇  tienes la caja de comentarios para lo que quieras.